Controllable systems for safe and reliable production processes
Every machine or plant in today's digital world consists of zeros and ones. Every computer and every mobile phone only processes zeros and ones. This is the smallest piece of information and can only describe two states. The BIT is thus present in every system. To simplify communication, we summarise all of them in the term ‘system’. Of course, every system has more than just one bit, quickly resulting in a very complex image of the individual bits. We refer to multiple bits as bit patterns. A bit pattern of 16 bits can mathematically describe 65,536 states. This complexity is also defined as a "State Explosion Problem". With 2 high number of bits, this results in very large state space. We call state space the number of possible bit constellations. This enables a system to communicate with the outside world via bit patterns. We would like to call the system an ACTUAL state because a system can output any bit pattern at any time.
Programming such systems in a real-time environment is a challenge
Programming describes the system’s behaviour and properties. The behaviour and properties are defined in a process. For a system to follow a defined sequence, input and output signals are processed. Outputs are switched, and feedback is expected as input. Or actions are executed on the system, and an input signal shows the activity. For example, if a button is pressed, then this action is recognised by an input signal.
The signals are logically processed in the controller. A real-time system reads the inputs in a cycle, processes the inputs logically in the control program and delivers the outputs. The controller actively interacts with the system through the output and expects the correct response via the input signals. The programmer now defines a machine for the desired logical sequence.
A deterministic finite state machine (DFA) has a primary position and a sequence of states or steps. The considerations for the logical sequence are the basis for any programming because the system must follow this process strictly and repeatedly. For more than 40 years, controllers have been programmed in the same way. The sequence is defined in states in a step chain. Starting from the primary position, the process flow is described step by step. There are two essential elements to this: the state and state transition (the transition).
For this purpose, DFAs are formulated, and the outputs are switched to each state; with the inputs’ feedback, the transition is fulfilled. A state change takes place. The states defined in the program are integer values shown in the machine's fictitious map (as in reproduction). This number expresses a state but has nothing to do with the system. The state of the system is not shown in this way.
For the transition, individual inputs are logically interconnected; this way, the system processes only partial signals. As a result, the programming maps an actual state, and the system is in an actual state (versus the target state). These two actual states (of the program and the machine) are not comparable. Hence, it is impossible to infer the machine’s state from the program.
Now, The programmer must program every error state from the system's complex number of possible states. Each bit pattern from the system would have to be programmed as faulty (error) or as allowed (validity). Since the number in the system quickly becomes very complex, known as the State Explosion Problem, the programmer can’t program all possible errors. This leads to the fact that in a usual program (as in best practice today), the system is not necessarily error-free if no error message is displayed. Yet it means that the error was not programmed. Manual programming using today’s methods is highly limited and incomplete. Many states in a system remain undefined, and precisely these conditions lead to misconduct and regular unplanned downtimes.
The Selmo Solution rethinks programming and reduces complexity to make systems fully controllable. The desired process is logically formulated in a DFA, like in today's programming. In contrast to traditional programming, we do not use fictitious values in the controller to describe the state. Selmo defines the entire required bit pattern as an allowed state. Thus, only the bit patterns defined in the process model are permitted. This creates a TARGET image of possible bit patterns in the system. All other bit patterns are not allowed and are thus automatically defined as errors.
Any deviation from a state is thus detected in bit-by-bit accuracy. This way, all states in a system are programmed. If no error message is displayed, there is no error in the system.
The state of the programme (target state) and the state of the system (actual state) are compared at all times. Any deviation is displayed as a bit-accurate error message so that the errors can be eliminated quickly and easily. This logic allows synchronisation between the program and the system. As an operator, I can either see the deviation of the system from my current state in the program and eliminate the deviation with simple operating steps or look for the right state in the programming that matches the state in the system.
The example shows that we have to accept that conventional manual programming does not produce completely controllable systems. This leads to many problems and uncertainties. With the Selmo Solution, we rethink programming and make programs completely controllable. The high level of standardisation in mechanical engineering and electrics has shown that this increases safety and interoperability. Hence Selmo is bringing the highest-level standards to programming.
Each system is guaranteed uniformly structured and operable. In the implementation, the Selmo Solution is easy to use and quick to learn. In operation, Selmo is unbeatably stable as programming, and in real time, any deviation is detected immediately and prevents long unplanned downtimes due to incomplete programming or misconduct that leads to expensive faulty production. Selmo is comparable to the ABS in the car. It is not needed when driving, but when braking, it can make the difference between life and death. When the machine is running, Selmo is not noticeable, but if a deviation is detected, it acts immediately and decisively, preventing expensive failures. Selmo, like the ABS in every car, now belongs in every machine, so that production is controlled and safe at the decisive moment.