In the context of this thesis, a control system can be centralized or distributed. In a centralized control system, all the control logic or software resides in a single processing or logic unit. Another form of a control system is a distributed control system where the control logic has been distributed in many interconnected units which thereby only execute a subset of the control loops of the system (Center for Chemical Process Safety, 2010, p. 264). In larger machinery applications, the latter case can be considered a more typical approach.
The definition of the desired system response could also include the idea of safety. That is, a desirably operating machine or process should retain the safety of the people that operate around it. However, safety systems and functions can be and have traditionally been separated from the control system (Sueur and Knobel, 2014, p. 2). Also International Electrotechnical Commission (IEC) acknowledges this approach (IEC, 2016). In this approach, a separated Safety Instrumented System (SIS) exists aside a control system. Currently also integrated control and safety system approaches are becoming available (School and de Groot, 2012). In the integrated approach, the control and safety systems are integrated from the user viewpoint but not necessarily implemented in a single common system. Still, regardless of the integration, the requirements for their development are distinct.
Regardless of the implementation approach, in both cases the purpose of a safety system or function is to reduce the risks to a tolerable level. In addition, safety functions typically do not participate in the productive system control functions. These tasks and functions are left for the control system and include, among others, the feedback control of a motor, the pressure control of a tank, and the path control of a robot arm. Still, both of the systems operate and affect the same system under control. This induces the need to make control and safety systems co-operate at least on some level so that the overall functionality of the system is desirable. An example of safety and control system co-operation and existence is given in the introduction of [P3]. Patterns considering the co-operation and co-existence of control and safety systems are discussed in Chapters 5 and 7.
2.6
On Safety System Development Processes
Figure 2.2 gives an overview of functional safety system development found on the (ISO 13849-1, 2015) and (IEC 61508, 2010). The thesis introduces design patterns considering the underlined parts of the process. The patterns are discussed in Chapters 5, 6, and 7. The process begins with the definition of the concept and scope of the system to be considered. This includes the boundaries of the system and the system’s assessment. In the next step, risk and hazards are assessed to provide a foundation for the risk mitigation work. The system safety requirements are defined and allocated reflecting the risk assessment results. In this phase, the risk mitigation methods are selected. For the scope of this thesis, the mitigation method is primarily considered to be a functional safety system.
The following part of the process is the development of the specified safety functions, that is, the functional safety system which implements the functions. This part of the process begins with the safety function requirement specification to define the function to be developed. Then, the hardware and software for the function are developed. The level of co-operation between hardware and software developers may vary. Regardless, the hardware and software are finally integrated into a functional element, and the performance of the safety function is validated.
18 Chapter 2. Functional Safety Systems and Their Engineering
Concept and scope definition
Risk assessment
System safety requirements definition and allocation
Development of safety function
Safety function requirement specification
Hardware design
Software design
Safety function system integration
Validation of safety function performance
Overall installation, commissioning and safety
validation
All safety functions implemented?
No
Yes
Modification or new hazard gererated?
Yes
Figure 2.2: A simplified process for safety system development according to (ISO 13849-1,
2015) and (IEC 61508, 2010), derived from [P2].
The development process is carried out for any subsequent safety functions. When all the functions have been developed, the complete system installation, commissioning, and validation can take place. If modifications are needed to the safety system, new hazards may emerge or risks may change. Thus new risk analyses and assurance cases are needed, which again can be based on the design patterns and standards referred by the design patterns of this thesis. Consequently, the process reverts to the risk assessment phase to make appropriate changes to the safety system.
3 Design Patterns
In this chapter, the concept of design patterns is introduced from generic and safety system specific perspectives. The chapter begins with the generic viewpoint and converges into more safety system related aspects at the end of the chapter. The purpose is to present design patterns and pattern languages as a framework, in which design artifacts are produced using the methodology described in Section 1.5.
3.1
Brief History of Patterns
The concept of patterns originates from the field of architecture. The book ‘A Pattern Language: Towns, Buildings, Construction’, by Christopher Alexander (Alexander et al., 1977) is typically seen as the starting point of patterns as they are considered in the design pattern community. The patterns by Alexander consider, among others, architecture, urban design and community building (Alexander et al., 1977, p. xix-xxxiv).
Thus, the origins of patterns reside in the domain of architecture, and it took some time before the concept of patterns was adopted into other domains of engineering. Eventually, in the late 1980s, the surge was sparked in the domain of software engineering as a result of the work by Beck and Cunningham (1987) presented in OOPSLA’87 (Eloranta et al., 2014, p. 80). This trend was advanced by Erich Gamma in his dissertation (Gamma, 1992, cited by Gamma et al., 2002) and especially the succeeding book ‘Design patterns: Elements of Reusable Object-Oriented software’ by Gamma, Helm, Johnson, and Vlissides (also known as Gang of Four (GOF)) (Gamma et al., 1995).
Since the 1990s design patterns have been identified and documented in various domains including, but not limited to, security (Schumacher et al., 2005), embedded systems (Douglass, 2010), teaching (Köppe, 2013), learning (Iba et al., 2009), cooking (Isaku and Iba, 2015), and business (Kelly, 2012). The variation of domains where patterns have been applied supports the idea of design patterns as a generic approach to document the solutions and practices of any domain.