Process control architecture

[EricLarsen]

I've been doing some brainstorming about my next project, and I would like to get ideas from this group for a good software architecture to use.

The application will be providing an operator interface to a bench-scale experimental process. The process is a fairly typical one; there will be a mix of valves, flow and pressure controllers, heating and cooling loops, thermocouples, etc. The process will be controlled by a Compact Field Point system.

In thinking about the software architecture, I envision a two layer approach. The top layer would be for the day-to-day operations. It would consist of modes like "startup", "operate", "shut-down". Each of these modes would have a series of operations that would occur at the start, such as "open Valve A, Set Flow B to X.XX, etc." The operator would select when the next phase would start, but certain criteria would have to be met before the next mode could happen, such as "temp T1>100, pressure P1>50". The idea here is that an operator does not have direct control over the components of the system, but only makes high level decisions about when to go from one mode to another.

The second layer would be where a trusted operator could directly manipulate the system, with commands such as "Open Valve A" or "Set flow B to X.XX". These kinds of commands would only be done during off-normal conditions. But there still need to be limits on when certain actions can be taken, such as "Valve A can only be opened when Pressure P1<50". There would also be alarm conditions that would trigger actions, such as "close valve B if temp T1>150".

This strikes me as a fairly typical software architecture. I'm no PLC expert, but isn't this is basically implementing ladder logic in software? I could hardcode a series of rules in the software, but I could see that quickly becoming unwieldy and hard to debug. Some kind of a rules based editor where I could go in and define the rules in advance and then quickly implement that in software would be ideal.

Any suggestions? Are there any resources out there that describe how to implement something like this in Labivew?

[Daklu]

Disclaimer: I've never done Compact Field Point programs, so this is from the perspective of a desktop applications programmer. Still, I think some of the principles would apply to CFP.

In thinking about the software architecture, I envision a two layer approach.

The two layers you're describing are strictly UI layers; they are not necessarily (and aguably shouldn't be) related to the how the application code is structured. If you tie the app's code structure too tightly to the user interface it becomes much more difficult to make UI changes when the users want to be able to do something different.

I can't offer any suggestions for a specific code architecture to use as it is highly dependent on your specific requirements. Instead I'll pose some questions that will hopefully help lead you to your answer.

• What's your timeframe? If there's enough "play time" in your schedule, you can explore new techniques and architectures. (Be careful though, learning a new architecture can will be a time sink!) On the other hand, if your schedule is fairly tight, stick with techniques you already know even if it produces less than ideal code.
• How much application design experience do you have in Labview or any other programming language, and what architectures have you used for previous apps? State machines are useful, but aren't the best solution for all applications.
• What's the expected lifetime of this application? If you know it's going to be used for 3 weeks and then thrown away you can get by with a less-robust solution than one that's expected to be used for 3 years. In general, apps with longer expected lifetimes need more up front design work making sure it is extendable and maintainable. (And that usually means more complicated code.)
• How much decision-making, either user-based or code-based, does your app require? Code complexity is directly related to the number of decisions that must be made during execution. More complex requirements need more complex solutions.

Assuming your app is on the complex side, will be around for a long time, and you want to make it fairly maintainable, here are some suggestions roughly in the order I would apply them:

1. Break up your application into logical modules. Don't just group all the VI's in a module in the same project folder. Create an lvlib for each module and make use of the private scope to hide the implementation details from the other parts of the program. Model-View-Controller is a powerful high-level architecture that breaks an application into user interface, business logic, and processing modules. You can also break down each of those modules down into sub-modules. (Reporting, File I/O, Valve Control, etc.) Modularity is the most important attribute for making an application extendable.

2. Within each module, use sub-modules to layer your code. Here is an article on using layering to create a Hardware Abstraction Layer. The principle applies to non-hardware functionality too.

3. Consider creating classes for key parts of your application. Note that modularity and layering can be accomplished using "traditional" Labview programming techniques (i.e. Structured Programming.) Using classes correctly can make it much easier to implement changes in the future. (Be warned, using them incorrectly will make your code harder to maintain.)

One last thought... be sure to talk to your users to find out what they need to do and how they want to view and interact with the application.