No-one wants to be writing the same code over and over again. Whether its for different projects, or in the same project. Having a standard, structured, yet flexible approach is very important in modern times.
Developing a modular approach for your current solution can be daunting, especially if you have time pressures or a particularly large collection of code, spanning many years, to refactor.
I have been practicing an Asset Oriented and Structured design pattern in PLC automation for many years. There are some real benefits in switching to a structured and modular approach to your design, but it can take considerable work and time, especially if you don’t know where to get started.
What Is A “Structured Approach”?
Almost any project can benefit from a structured approach and the above example can be applied to any project at the design stage.
Essentially, the structured approach is split into 5 basic areas, with additional areas optionally added if needed
- Input Abstraction Layer
- Gathers information from the Hardware and stores them in tags
- Gathers information from the Hardware and stores them in tags
- Input Mapping Layer
- Using a standard approach for an Asset type, accepts input signals and copies them to a standard Asset Data Block. The data block is composed of User Defined Types (UDTs) to ensure a structured design pattern and hierarchical approach
- Using a standard approach for an Asset type, accepts input signals and copies them to a standard Asset Data Block. The data block is composed of User Defined Types (UDTs) to ensure a structured design pattern and hierarchical approach
- Standard Asset Management
- A dedicated, library version controlled, Function Block accepts the entire Asset Data Block as an input (complete with input data) and effectively manages the current status of the asset.
This includes:- Alarm management
- SCADA / HMI status management
- Specific asset functions (such as signal damping for an analog device, or status word monitoring for a VSD)
- Output request management – Generating output requests for the Output Mapping Layer
- Standard interlock management – Create interlocks for use outside of the Function Block
- A dedicated, library version controlled, Function Block accepts the entire Asset Data Block as an input (complete with input data) and effectively manages the current status of the asset.
- Standard Interlock Generation
- The Standard Asset Management creates standard interlocks for the specific device in use. These interlocks are stored in the Asset Data Block and are then used by other devices and processes to control logic requirements.
Methods to omit standard interlocks not required for the project are also included
- The Standard Asset Management creates standard interlocks for the specific device in use. These interlocks are stored in the Asset Data Block and are then used by other devices and processes to control logic requirements.
- Output Mapping Layer
- Extracts Output Requests from the Asset Data Block and writes them to Output Tags, which drive the output hardware to physically action a signal or device.
Additional Considerations
Once the standard approach has been defined, we can then look at other specifics or add-ons, such as:
- System Generation
- A collection of Assets that come together under one versioned & Library Managed Function Block to control a system. This approach may use multiple Asset Data Blocks and even a dedicated System Data Block. A system is designed to be drag-and-drop in its own right, with all requirements clearly defined
- A collection of Assets that come together under one versioned & Library Managed Function Block to control a system. This approach may use multiple Asset Data Blocks and even a dedicated System Data Block. A system is designed to be drag-and-drop in its own right, with all requirements clearly defined
- Alarm Management
- There are multiple ways to generate standard alarms at an asset level. These can be explored as more is understood about the end requirements. Ultimately, the alarm approach will always be device specific, alarms are raised by the Asset Function Blocks in the same way for each asset.
- There are multiple ways to generate standard alarms at an asset level. These can be explored as more is understood about the end requirements. Ultimately, the alarm approach will always be device specific, alarms are raised by the Asset Function Blocks in the same way for each asset.
- Simulation
- With a dedicated Input Mapping Layer and UDTs, every signal for every asset is already known. Because of this, we can build a Simulation Layer, which can act as a substitute for all Input Signals. This approach isolates signals before they enter your Asset Function Blocks, meaning the simulation itself cannot introduce errors to your process testing. If the asset behaves one way under simulation, it will behave the same way with real input signals too.
Consultation
There are different levels of consultation for approaching an architecture design such as this. If you are starting from scratch, things may be easier than starting from a “loosely standard” start point.
In any case, I will do my best to find where things can be easily standardised across your current suite of code objects.
Consultation packages are 100% tailored to you as an end client. Whether you need help with redesigning function blocks to be more modular, or need help with creating UDTs for future projects, I can help ensure a standard approach is undertaken to ensure a reusable outcome.
Please check out my LinkedIn and posts on this website for a feel of what I’m about
I have experience with Siemens, Allen Bradley, Schneider, Mitsubishi and more. However, the structured design principle can be applied to almost any modern PLC with a symbolic approach.
Let’s Talk
If this sounds interesting, or you want more information, simply drop me an email and we’ll arrange to talk through this in more detail.
