Picking up support for existing application - starting information

[general_man]

Hi everyone. I'm new here and I'm going to start with a fully loaded question. I'm also not an electrical or software engineer so my terminology is likely to be different to yours. Sorry about that. No-one's perfect.

Let's say John Smith has a fairly complicated piece of technical equipment that is composed of a number of electronic devices like pumps, motors, drives, switching valves, feedback loops etc. Let's say this gizmo is controlled by a LabVIEW FPGA system with 0-10V and 4-20 mA device connections and cRIO board, with a PC-based HMI. It can run sequences of operations in full automatic mode or can operate individual devices via the HMI in manual mode.

Now let's imagine that the machine was built by 'Acme Machine Corp', who sub-contracted the electrical system design and software development and coding to 'Software Solutions R Us'. I made those names up for sake of example.

Let's say that Acme Machine Corp and Software ... R Us did a great job and all is working until some day John Smith wants to make a change to his machine, add new equipment or change the purpose and therefore requires a software modification project. Or maybe things break down, and there is a software integration angle to the repair process.

OK fine, but what then if Acme Machine Corp, or Software ... R Us has gone out of business and there is no source code for the machine other than the executable file and perhaps some of the .VI files? The machine is dead.

What would you guys, who presumably code this stuff day in day out, need to see in order to pick up support for someone else's system?

What should John Smith have got from Acme during the machine handover to insure against this situation?

What challenges would you face coming into this situation with only the master control computer and HMI and the pre-installed software? What makes your life easier - and the job cheaper?

Like I said, an open question and probably not phrased very well.

The easy answer is John should learn to code, but let's assume John is a chemical engineer and will out-source this to a skilled and qualified contractor.

[Terry_ALE]

Step 1: get your documents in order

[crossrulz]

Assuming you are a Chemical Engineer, what would you need in order to recreate a compound?  You would need documentation of some type for how it was made.  Same for electrical and software.  Schematics and source code are pretty much required in order to do any maintenance.  If you insist on keeping the machine and you have no schematics, then you will be looking at a long drawn out process examining the wiring and parts, etc. to recreate a schematic and then analyze it to see what the software needs to do.  With no source code, there is NO maintenance you can do.  It will be a complete rewrite.

So it seems to me the best route would be to lay down all of your requirements and have somebody build a new machine.  And make sure all documentation (schematics, build instructions, source code, etc) is part of the deliverable product.  Then if the designer goes out of business or whatever, somebody else can just look at the documentation and code and do the updates needed.

[general_man]

Yes, thanks, quite right both. Of course full and complete wiring and electrical layout diagrams, cable schedules should be in the deliverables along with the things a chemical engineer is more familiar with like P&IDs, assembly dwgs, line & valve schedules etc.

Question is more about what other documentation is needed specific to software. OK maybe you have the exe file and the vi's but with the wiring details is that enough?

Some of the source code / sub-VIs may be proprietary, so what would you need there? schedule of all these parts, what they do, where they sit in the main code, their "serial number" or unique identifier so they can be pulled from NI archives?

This isn't my field, at all.

[crossrulz]

---

@general_man wrote:

Some of the source code / sub-VIs may be proprietary, so what would you need there? schedule of all these parts, what they do, where they sit in the main code, their "serial number" or unique identifier so they can be pulled from NI archives?

---

There is no "NI archives" for code that has been written by other companies.  NI has their own source control procedures for anything they release.  And all of that should be readily available in the LabVIEW IDE.  So those are not a concern.  But code written by company "A" that they deemed proprietary and refuse to share is basically dead to the world.  If we can't see the code, it is useless and therefore we are back to the rewrite scenario.

You cannot revert an EXE into code.  So as far as maintenance is concerned, that is also useless.

[general_man]

Source code is indeed in with the deliverables albeit with a caveat about some proprietary sub routines and major NI blocks.

I assume the NI blocks are not a risk provided the What, Why, Where and How is specified.

So .vi files and the .exe are next to useless as far as rebuilding the system is concerned, for a non software guy what format is sensible? Would this be essentially a text file of the un compiled code verbatim?

[Gregory]

---

@general_man wrote:

Source code is indeed in with the deliverables albeit with a caveat about some proprietary sub routines and major NI blocks.

---

What does proprietary sub routines mean? Is the block diagram password protected? As long as you don't need to edit the password protected VIs, that is fine, you can still build them into an executable.

When you say NI blocks do you mean toolkits? If so, you would have to purchase the missing toolkits in order to run any VIs dependent on them, or build an executable. You can also check the machine's "NI License Manager" to see what toolkits are installed.