Problems with the control design

<< Click to Display Table of Contents >>

Navigation:  Welcome to SELMO  > Method >

Problems with the control design

In the beginning, there is a functional specification of what is to be done. Due to the complexity mentioned above, the information often only comes gradually from the various knowledge carriers.  The process of control design can be divided into individual steps.  The terms used, which are often used differently, are to be defined in the field of control engineering. (Litz & Frey, Apr.1999)



.Figure 6-2: Procedure for control system design




The informal specification is the starting point for the control engineer. This includes everything that is not based on a strictly defined theoretical basis (verbal descriptions, sketches or free flow diagrams).  

The informal specification can include: a description of the controlled process (e.g. plant schematics or RI flow diagram according to DIN 28004 and DIN 19227)

Requirements for the controlled process

Direct requirements for the control algorithm


Since such task descriptions are not based on a well-defined syntax and semantics, they cannot be checked beyond doubt for completeness, unambiguity or freedom from contradictions.


Formalisation is the conversion of the informal specification into the formal specification. This is a human achievement and is the key to the systematic solution of the control task.  


The formal specification requires knowledge of suitable methods and tools as a prerequisite. Well-known methods are systems of Boolean equations, finite automata or Petri nets. As a new method, zone programming is to be applied, compared and checked for quality criteria.


Ideally, the implementation consists of an automatic code generation by the design tool depending on the target system and is based on the formal specification.


The implementation always consists of a combination of hardware and software, involving several software levels such as real-time operating system, communication software, algorithm software. If one uses standard systems with well-defined functions, such as PLCs, the end result is the software at the algorithm level.  Here, standardisation through IEC 61131 can be regarded as the state of the art.


Validation provides information on the extent to which the entire control system fulfills the intended functions. Validation is carried out across all steps and provides the opportunity to uncover errors in the formalisation of the task. Incomplete or contradictory specifications in the informal specification can be detected, which often leads to a change of the originally given (a posteriori invalid) specification.


Direct implementation is still the most common approach to realising informal specification in the everyday industry. This means that the possibilities of the formal specification are not even used. Unfortunately, the direct way offers many possibilities for errors and changes due to the results of the validation are usually costly or impossible. Commissioning is often a lengthy process and any malfunctions that occur are difficult to rectify.




Starting from the informal specification with the description of the technical equipment, process behaviour, actuators, sensors, technological boundary conditions and the user requirements, the formal specifications are generated. These are the models for the behavioural requirements, the control algorithm and the control path. Cf. (Litz L. , 2005, p. 188) The technological boundary conditions can be taken into account in the model of the control path. The transformation of the informal specifications into the formal representation is not automated and is thus a challenging engineering task to the full extent.


The fourth branch is dedicated to the transfer and consideration of the requirements for the interface to higher-level systems and to humans, as shown above. The requirements of control towards humans are described in more detail under the quality criteria and will be discussed in detail later.