Software standardisation: the ins-and-outs
21 July 2020
As has been outlined in a previous blog, standardisation (preferably multidisciplinary) has become a hot item nowadays. Various departments – such as hardware, software and mechanical engineering – are jointly responsible for designing standardised products. In this blog we focus on software standardisation. What does it involve exactly? What should you look out for? We shed light on a number of aspects.
Software standardisation always involves a number of choices. As such, for software there’s no one correct answer to a problem or issue: in fact, several correct solutions are possible. So, you would think, that makes things easier. But it is precisely because several options are available that it is difficult to come up with a software standard that satisfies everyone. Every solution has its pros and cons and every software engineer has his or her way of doing things. That’s what makes it difficult.
So, what are the choices that must be made? Take the following, for example:
- Structure: what stratification should be made in the software?
- Arrangements regarding nomenclature/identifications
- Alarm management: how should alarms be saved? At what level should alarms be saved? And are all the alarms for the whole project located in the same place, or are they in one place per machine part/process part?
- Parameters: how and where do I save the parameters/settings?
- HMI/SCADA: Is it my aim to have all motors, valves, measurements, etc. controlled separately, for example, by means of a pop-up?
.
Structure
One of the first things to be considered is structure. How should the software be structured? How should it be divided: into sections or units, for example? Or in a functional decomposition? To determine the structure of the software, there are guidelines which might help in this, such as the ISA-S88 / PackML. If you are a machine builder, the software can be harmonised to match the machines you produce. If you are a systems integrator, you can choose to create a single software standard which is flexible enough for different clients using different machines or processes. Another option, of course, is to develop a separate standard for each individual client.
In all cases, the lowest ‘layer’ of a system can always be standardised in the form of function blocks. These might be motors, valves, etc. for example. These are the control modules according to the S88. After all, a motor is always operated in the same way. With parameters (e.g. a brake or no brake), these function blocks can be used again and again, for all projects.
Standardising the layers above this is usually more difficult. It is in these layers that the logic of the project is present, such as controls and step-by-step workflows. These can be predefined for a machine builder, but for a systems integrator this is more difficult. Nevertheless, these layers too can be standardised by structuring the function blocks for these layers in a standard fashion. Indeed there is no logic yet, but the structure and layout have already been determined. And that’s a big plus point here.
.
Reaching agreement
It is a good idea to agree on nomenclature/variables, for example. Do you have all the inputs of the function blocks begin with the letter ‘i’, and the outputs with an ‘o’? Or do the variables start with a code which explains which type it is (e.g. a ‘b’ for boolean and an ‘i’ for an integer)? Do you then use underscores or Camel case for variables (so, either ‘Pump_Auto_Start’ or ‘PumpAutoStart’)?
Other nomenclature plays an important role, too. For example, the names for the variables that are used for the link to I/O. And what about the names of functions and function blocks?
Other aspects you can reach agreement on include:
- The language used for programming
- Commentary on variables
- Commentary and title for a network
- Mixed or non-mixed languages in one function block
- Use or not of global variables in a function block
- Etc.
.
Functional questions
There are also a number of functional issues that require consideration. For example, do you want to be able to operate all control modules separately from HMI/SCADA? This could be done with a pop-up. On the pop-up screen, it is possible to configure a motor in manual mode, so that the motor can be switched on and off from the pop-up. This might then give rise to the following questions: should I set the motor to manual mode if there are alarms? Can I change the parameters of the motor just like that, or do I need to be logged in at a particular level? Each of these is a functional question, which is useful to answer in the process prior to standardisation.
.
Hardware
You must think carefully about hardware too. For example, you will want to avoid creating several standard function blocks for different makes of frequency regulators. It’s better to pick out two makes and to focus the software on these. That leaves the client with some kind of choice. If the client really does want another make, that’s still possible of course. In this scenario however, you can no longer make use of your standard function blocks and this will result in longer lead times for the project.
.
Finally: decision time
The conclusion we can draw is that it is quite feasible to define a standard for a software department which everybody supports. The specific choices however, can be a subject of long debate. All well and good, but at a certain point you will have to take a decision. From that point of view it’s important to appoint someone who has the final say.
Once a standard has been created which has the support of everyone, this will give the engineers more time to spend on a project’s ‘specials’. At that point no one needs to think in terms of ‘standard’ software, because that’s a given. This will not only improve the quality; but also reduce the number of breakdowns (bear in mind the breakdown service). Does your software standard enjoy a broad consensus? Or do you need a partner to set up a standard? If so, feel free to contact us!