Standardization (preferably multidisciplinary) is a hot topic these days. Different departments – such as hardware, software and WTB – jointly design standardized products. In this blog we focus on software standardization. What does this all entail? What should you pay attention to? We will explain a few aspects.
Software standardization is ultimately always about making choices. In software, there is never one right solution to a problem or issue; there are always multiple right solutions. Then there is nothing difficult about it, you would think. But the fact that there are multiple possibilities makes it difficult to arrive at a software standard that everyone supports. Each solution has its own advantages and disadvantages and each software engineer has his own way of working. That makes it difficult.
What issues do you have to make choices about? These include:
- Structure: what layers do I apply to the software?
- Naming/identification agreements
- Alarm handling: how do you store the alarms? At what level do you store the alarms? And are all alarms of the entire project in one place, or are they in one place per machine part/process part?
- Parameters: How and where do you store the parameters/settings?
- HMI/SCADA: Do I want to be able to operate all motors, valves, measurements, etc. separately, for example by means of a pop-up?
.
Structure
One of the first things you need to think about is the structure. How do I want to build the software? How do I want to divide the software, for example in sections or units? Or in a functional decomposition? To determine the structure of the software, there are guidelines that can help, such as ISA-S88 / PackML. If you are a machine builder, you can fully tailor the software to the machines you make. If you are a systems integrator, you can choose to create one software standard, which is flexible enough for different customers, with different machines/processes. It is of course also possible to create a separate standard for each customer.
In all cases, the bottom 'layer' of an installation can always be standardized in the form of function building blocks. Think of motors, valves, etc. These are the control modules according to S88. After all, controlling a motor always works the same. With parameters (with or without brake, for example) you can use this function building block again and again, in all projects.
Standardizing the layers above is usually a bit more difficult. The logic of a project is present in these layers, such as regulations and step-by-step processes. For a machine builder, these can already be predefined, but for a systems integrator this is more difficult. However, you can also standardize these layers in the form of a standard structure of the function building blocks of these layers. There may not be any logic in it yet, but the structure and design have already been determined. And that is already worth a lot.
.
Dates
It is good to make agreements about naming/variables, for example. Do you let all inputs of a function building block start with a lowercase 'i', and the outputs with an 'o'? Or do the variables start with a code that shows what type it is (e.g. the 'b' for a boolean and 'i' for an integer). Do you then use underscores in variables or do you write the CamelCase (so either 'Pump_Auto_Start' or 'PumpAutoStart')?
Other names also play an important role. For example, the names for the variables that are used for the connection to I/O. And what about names of functions and function building blocks?
Other matters you can make agreements about:
- In which language is programming done?
- Commenting of variables
- Comment and title on a network
- Mixed languages in one function building block yes/no
- Whether or not to use global variables in a function building block
- Etc.
.
Functional questions
There are also functional issues that you need to think about. For example, do you want to be able to operate all control modules separately from HMI/SCADA? This could be done using a pop-up. On the pop-up screen, it is possible to put a motor in manual mode, so that the motor can be switched on and off from the pop-up. The following questions could then arise: can I switch the motor on in manual mode if there are alarms? Can I simply adjust the parameters of the motor or do I need to be logged in with a certain level? These are all functional questions, and it is useful to answer them in the preliminary phase of standardisation.
.
Hardware
You also need to think carefully about the hardware. For example, you do not want to create multiple standard function building blocks for different brands of frequency controllers. It is better to choose two brands and set up the software for them. Then the customer still has some choice. If the customer really wants a different brand, that is of course still possible. However, you cannot use your standard function building blocks, which results in a longer lead time for the project.
.
Finally: cutting the knot
We can conclude that defining a standard for a software department, which everyone supports, is certainly feasible. You can discuss certain choices for a long time. This is good, but at some point decisions have to be made. It is therefore important that a responsible person is appointed who can and may make decisions.
If at some point a standard is created that is supported by everyone, then the engineers will be able to invest more time in the 'specials' of a project. They no longer have to think about the 'standard' software, they can rely on it. This benefits the quality and indirectly also in reducing the number of faults (think of the fault service). Do you already have a widely supported software standard? Or do you need a sparring partner in setting up a standard?
We regularly give webinars on this topic. Interesting? Join us!
Nederlands