Control System Architecture (Beckhoff)

[Kalavrat]

I'm preparing architecture for a fairly complex control system (technology stack is Beckhoff, so OOP etc is available).

The system has many controlled devices, each device is associated with a setpoint and a readback value + several config values (limits, scaling etc).

The parameters (setpoints, limits, scaling) need to come from external database.
The same set of parameters is exposed out to the device adapters
The same set of parameters is exposed to HMI for viewing and modification.

Is there an architecture pattern that I can follow to handle this in elegant manner?

My initial idea was to bundle the parameters into structures so that each device is only interested in single struct- The component that handles database should be the owner of the parameters and devices / HMI should only get references to those.

It feels like this should be a common problem, so I'd be interested to hear how you normally tackle this.

 

[drbitboy]

I don't know enough about the process to suggest specific protocols, databases, etc.

But one piece of the architecture would be critical in my mind: there must be only one place in the system were the "official" values are known; in your case I believe that place is the "database," whatever that means. For example, you do not want the HMI to update values directly in the PLC, because then the values in the database would be "stale." Better to have the HMIm and any other entity that can change the value, write to the database, and have the writing of a new value to the database trigger writing that value to the PLC.

The details of the "database," and how an update event triggers pushing data to downstream processes, is TBD. I am fairly certain this capability exists in multiple forms, but the protocols available to the various pieces may limit what tools are suitable to the task.

CD/CI tools common in software development implement a similar process. For example, the mechanics of this could be implemented with a central Git server. Git has "commit hooks" built into its architecture, so any updates can be

• checked for validity before committing the new value (pre-commit hook)
• posted to downstream processes after the commit (post-commit hook)

The interesting work will be interfacing all the pieces ("database," HMI, PLC), so Git is actually unlikely to be a good choice for this because all of the custom interfaces that would be required.

Also, one problem with a central server is what happens is that server, or connectivity to that server, stops working. Would it be acceptable to not be able to update parameters in that situation? I wouldn't say this changes the primary importance of a single server, just that what happens when some subsystem fails needs to be considered.