CARACTERIZACIÓN MICROESTRUCTURAL

idea/solution Write a prototype pattern The proto is satisfactory? Publish or archive the prototype pattern yes no Improve the prototype pattern

Figure 5.1: The pattern mining process applied in the initial phases of the research.

feedback on the prototype patterns from the pattern community through PLoP conferences. The review process of the conferences and constructive criticism received in the workshops is considered here as the quality control of the suggested patterns.

5.3

Results

The categories of the patterns considered in this chapter include architecture and co- operation related aspects in terms of control and safety system and their development. The categories (on the right-hand side) and the topics within the categories and their relations are depicted in Figure 5.2.

The architecture category considers the structure and behaviour of the system, and the principles regarding the operation and the design of the system. The System architecture patterns include Hardware architecture as well as software architecture aspects, which again are divided into structural and behavioural aspects. The Software functionality topic considers the behavioural aspect of the software.

The co-operation category considers the roles of control and safety systems and their separation, the co-existence of the systems, and finally the need to override a control system if a safety system decides so. The included patterns build on the idea of separation between control and safety systems, but some of them can be potentially applied also in case the safety and control systems are integrated.

The Safety and control system separation topic is the starting point in the category. The patterns in the topic consider separation and consequent responsibilities between safety and control systems. When the safety and control systems are separated, the need to operate and control the same system with distinct objectives arises. The Co-existence with control system topic provides ideas and design solutions for such a situation. Finally, a safety system must be able to decide whether a system operation, for instance, movement, start-up, or energization is safe or not and consequently dictate whether the operation is allowed or not. For this purpose, a set of Control system override patterns has been documented. The purpose of these patterns is to provide a safety system with an ability to override a control system and bring the system under control in a safe state.

It should be noted that all the patterns could be somehow categorized under the archi- tecture category. They all tend to consider either the structure or the functionality of a system. In addition, this may be implemented in either software or hardware.

36 Chapter 5. Control Systems, Safety Systems, and Their Co-existence CONTROL SYSTEM OVERRIDE SAFETYAND CONTROL SYSTEM SEPARATION SOFTWARE FUNCTIONALITY induces need for leads to safety system’s SYSTEM ARCHITECTURE includes CO-EXISTENCE WITHCONTROL SYSTEM HARDWARE

ARCHITECTURE includes ARCHITECTURE

CO-OPERATION

Figure 5.2: High level categorization of the patterns in this chapter.

5.3.1

Patterns for Control and Safety Systems and their

Co-existence

Table 5.1 summarizes the patterns for control and safety systems and their co-existence presented in this thesis. The table gives the pattern name pattern, the short description of the pattern patlet, and the status of the pattern, where P equals a pattern (with at least three known uses) and a PC equals a pattern candidate, with less than three known uses. Table 5.2 summarizes the patterns referenced in the patlets of Table 5.1.

Table 5.1: Patterns for control and safety systems and their co-existence. The patlets have

been reproduced here from the referenced publications.

Pattern Patlet Status

Check physi-

cal response, [P3]

Operations and commands executed in software may suc- ceed or fail in the physical world though software con- tinues execution. Therefore, use sensors to ensure that operations executed in software have the presumed effect in the physical world.

P

Control sig-

nal blocking, [P8]

A safety system needs to have the ability to drive the system under control or the process variable of interest into a Safe state regardless of the operations of a control system. Therefore, override a control signal produced by a control system with a suitable blocking device controlled by a safety system.

P

Control sys-

tem notifica- tion, [P8]

The operation of a control system is disturbed when a safety system overrides or restricts the operation of the control system, which may cause the unexpected be- haviour of the control system. Therefore, make a control system aware of the state changes of a safety system so that the control system can react accordingly.

5.3. Results 37

Table 5.1 – continued from previous page

Pattern Patlet Status

Co-operative

safety re-

lated actua-

tion, [P8]

How to increase the consistency between the operation of a safety system and a control system during situations where the safety system overrides the control system partly or completely? Let a safety system drive a control system into a Safe state whenever a safe state needs to be obtained (according to the safety system).

P

De-energized

safe state,

[P3]

Power supply for the safety system and the control system as well as the system under control cannot be guaranteed, which might inflict a hazardous state during blackout or power loss in (part of the) safety system. Therefore, design the safety system (and control system as well if applicable) to take the Safe state when power is lost. Related standards: (IEC 61508-7, 2010, section A.1.5)

P

Hardwired safety, [P3]

Development of safety-related application software is costly and provides no real benefit in the context of the considered safety function. Therefore, use a hardware- based safety system instead of application software to implement the safety functionality.

Related standards: (IEC 61508, 2010)

P

Indirect re-

sponse check, [P3]

Adding dedicated hardware for checking that operations executed in software really occurred in the physical world is costly and increases the complexity and the spatial properties of the system. Therefore, check operation success by indirect indication.

PC

Output inter- locking, [P3]

Implementing protective functions in control algorithms makes the control algorithms complex. Therefore, use an interlock element alongside each control actuator output in the control system.

P

Productive safety, [P8]

A system under control should be kept in an operational region for as long as possible to avoid the activation of safety functionality while the functionality of a safety system should be kept minimal in comparison to control functionality. Therefore, implement corrective functions in a control system and use the simplest approach for the safety system functionality.

P

Safety lim-

iter, [P8]

A safety system needs to have the ability to drive a system under control or a process variable of interest into a Safe state regardless of the operations of a control system. Therefore, let the safety system manipulate the control signal before directing the control signal to the actuator.

38 Chapter 5. Control Systems, Safety Systems, and Their Co-existence

Table 5.1 – continued from previous page

Pattern Patlet Status

Separated override, [P8]

A safety system needs to have the ability to drive the system under control or one of its process variables into a Safe state regardless of the operations of a control system. Therefore, use separate actuators for safety and control systems.

P

Separated safety, [P8]

Designing a whole control system according to safety standards is a costly, bureaucratic, and slow process. Therefore, divide and separate the system control func- tionality into two separate entities: a control system and a safety system.

Related standards: (IEC 61508, 2010; ISO 13849-1, 2015) P

Shared safety actuator, [P8]

Providing each subsystem with a dedicated safety actu- ator when the same input variable is used by multiple subsystems increases the number of needed safety ac- tuators in the system. Therefore, use a shared safety actuator for all the subsystems.

P

Table 5.2: External patterns referenced in the aforementioned sources. The patlets have been

reproduced here from the referenced publications.

Pattern Patlet Status

Control sys-

tem, (Eloranta et al., 2014)

The productivity of a work machine cannot be increased any further using traditional ways of building the machine – using hydraulics, electronics and mechanics. There-

fore, implement control system software that controls the machine and has interfaces to communicate with other machines and systems.

P

Limit number

of retries,

(Rauhamäki et al., 2015)

A retry approach to achieve fault tolerance may lead to an infinite loop. Therefore, limit the number of retries per occurred fault to a reasonable level within time tolerances. PC

5.3. Results 39

Table 5.2 – continued from previous page

Pattern Patlet Status

Safe state,

(Eloranta et al., 2014)

When the control system tries to control a part of the ma- chine that is malfunctioning, the machine may respond in an unpredictable way. Consequently, the machine may harm the operator, machine or surroundings. These kinds of situations should not take place. Therefore, design a safe state that can be entered if the control system encounters a malfunction that cannot be handled autonomously. The safe state is such that it prevents the machine from causing harm. The safe state is device and functionality dependent and is not necessarily the same as the unpowered state.

P Small sub- system fault detection, (Rauhamäki et al., 2015)

It is problematic to transfer substantial amounts of infor- mation to high-level subsystems considering faults. There- fore, apply fault detection on as low a subsystem level as possible and aggregate fault information for higher-level subsystems.

PC

5.3.2

Pattern Topic Categorization

Figure 5.3 categorizes the patterns given in Table 5.1 under the categories defined in Figure 5.2. The figure also indicates the relations between the E/E/PE safety system pattern (see Table 6.1) and the topics considered here, to show the relations between patterns discussed in different chapters. The topics describe the main area of concern regarding the included patterns. That is, for instance, the topic of the Hardwired safety pattern is Hardware architecture.

5.3.3

Pattern Purpose Categorization

Figure 5.4 illustrates the purpose of the patterns. Here, the purpose describes the target outcome or result of the application of the pattern. In the context of the patterns discussed in this chapter, the following purpose categories were defined. It can be argued that each or most of the patterns illustrated in Figure 5.4 could be included in more than one purpose category, but for the sake of clarity, such more refined categorization is omitted here.

Control and safety system co-existence The main objectives of control and safety systems differ substantially and a safety system is typi- cally able to override a control system. Thus, it is beneficial for both systems that they operate in a coherent way.

40 Chapter 5. Control Systems, Safety Systems, and Their Co-existence E/E/PE SAFETY SYSTEM SEPARATEDOVERRIDE CONTROLSIGNAL BLOCKING SAFETYLIMITER CONTROLSYSTEM OVERRIDE PRODUCTIVESAFETY SEPARATEDSAFETY SAFETYANDCONTROL

SYSTEMSEPARATION CHECKPHYSICAL RESPONSE INDIRECTRESPONSE CHECK SOFTWARE FUNCTIONALITY implements induces need for leads to safety system’s DE-ENERGIZEDSAFE STATE SYSTEMARCHITECTURE includes CO-OPERATIVESAFETY ACTUATION OUTPUTINTERLOCKING CO-EXISTENCEWITH CONTROLSYSTEM CONTROLSYSTEM NOTIFICATION HARDWIREDSAFETY SHAREDSAFETY ACTUATOR HARDWARE ARCHITECTURE includes may benefit from

Figure 5.3: Control, safety and co-existence patterns arranged according to their topic

COMMANDSUCCESS CONFIRMATION

SOFTWARESCOPE REDUCTION

CONTROLANDSAFETY SYSTEMCO-EXISTENCE

SAFETYSYSTEMSCOPE REDUCTION

HARDWAREREDUCTION

OVERRIDINGCAPABILITY FAULTTOLERANCE

FAIL-SAFEONPOWERSUPPLY BREAKAGE

SAFETYLIMITER

PRODUCTIVESAFETY

SEPARATEDSAFETY CHECKPHYSICAL RESPONSE INDIRECTRESPONSE CHECK SHAREDSAFETY ACTUATOR DE-ENERGIZEDSAFE STATE CO-OPERATIVESAFETY- RELATEDACTUATION OUTPUTINTERLOCKING CONTROLSYSTEM NOTIFICATION HARDWIREDSAFETY SEPARATEDOVERRIDE CONTROLSIGNAL BLOCKING