An Agile Development Process for Petrochemical Safety Conformant Software

An Agile Development Process for Petrochemical Safety Conformant Software Thor Myklebust MSc, SINTEF Tor Stålhane, PhD, IDI NTNU Narve Lyngby MSc, SINTEF Key Words: SafeScrum, IEC 61511, Safety-Critical Software SUMMARY & CONCLUSIONS The cost of software development is one of the major contributors to the development cost for safety systems in the petrochemical industry. It is hard to make developers work faster but it is possible to make them work more efficient. One way to achieve that is to introduce agile development methods. Agile methods are gaining increasing popularity in safety critical areas such as the petrochemical industry. Agile methods promise reduced costs and shorter time to market through incremental development, less production of unnecessary documents and more maintainable code. The IEC 61511:2003 standard is normally used by the petrochemical industry. The second edition of this standard will be issued in 2015. Both the current and the new draft edition IEC 61511:2014 of the IEC 61511 standard are evaluated against agile development approach in this paper. Both editions of the IEC 61511 standard have a strong link to IEC 61508. Manufacturers and suppliers of devices shall use IEC 61508, while system designers, integrators and users shall use IEC 61511. The IEC 61508 standard s relationship to agile development has been evaluated with success in a previous paper (Stålhane 2012). While the architectural design also in agile development is done up front, detailed design is done incrementally. Based on reported experiences in other domains, we expect the following benefits: Easier to discover and correct faulty or incomplete system requirements Simpler software, thus reducing the development and maintenance costs Only documents that are needed, either for certification or development, are developed The ones that are developed are used and kept up-to-date Improved opportunities for reuse and site development. The challenge is to introduce agile development without compromising safety. Development of safety systems needs to be compliant with IEC 61511. This standard impose rigor and additional costs, but proper adaptation of agile methods can add flexibility and efficiency. In order to evaluate this proposition we use a three step process: Go through all relevant requirements in the standard and mark all requirements as (1) fully met using agile development, (2) possible to meet using agile development and (3) cannot be fulfilled "as is" using agile development. All requirements in category (2) are studied further in order to assign them to category (1) OK, category (2) - adaptations to the agile method by including add-on's or category (3) changes to the development process. Suggest appropriate modifications to the agile development. This is the same process that we have used with success for IEC 61508 (Stålhane 2012) and IEC 60880 (Stålhane 2013). The work on IEC 61508 resulted in a method called SafeScrum. The SafeScrum model are reused and improved to fit the current and new edition of IEC 61511. There are no requirements in the current standards that prevents for an adjusted agile development process as SafeScrum. When the issues identified as category 2 in section 2 are settled, it should be straight forward to use SafeScrum and still be IEC 61511 conformant. It is now important to get one or more companies to try it out in cooperation with the certification bodies and / or authorities to get a reality check of the concepts discussed. This will allow us to identify possible problems and to make the adjustments necessary for industrial application. The main challenges are the IEC 61511 requirements on configuration management, traceability, detailed planning and documentation. However, in order to reap the full benefits of agile development, it is not enough to show conformance to IEC 61511. Suggested improvements of IEC 61511 are more requirements and information regarding modern software development methods. This is also in accordance with preliminary work performed by the current IEC 61508-3 maintenance committee. Acknowledgements: This work was funded by the Norwegian Research Council under grant #228431 (the SUSS Project, Agile development of Safety Critical Software) and the internal SINTEF Safe Software project.

1 INTRODUCTION Agile development methods such as Scrum are used in more and more areas of software development (Fitzgerald 2013). For safety critical systems, however, some safety engineers feel that agile development does not fit, the main reason being that these projects require a strict plan which makes later changes costly (Redmill 2014). Still, safety critical projects in e.g., process industry projects, suffer from many of the same problems that mare other software development projects, such as the need to change plans and requirements, being too late and having a solid budget overrun. Our contribution to solving this problem is an assessment of how we can adapt and develop the SafeScrum model (Stålhane 2014). It is assumed that that an adapted model can be used by the Process industry, including the Offshore domain, which uses the IEC 61511 standard. Even though the model was developed for the IEC 61508 standard it can be used without losing the benefits that we get from these concepts. We have also evaluated the differences in adaption of the SafeScrum model that are necessary for IEC 61508 and IEC 61511, together with a proposal how the new edition of IEC 61511 should be improved. 1.1 IEC 61511 The IEC 61511 is the process industries implementation of IEC 61508 for safety instrumented systems (SIS). A SIS is defined as an instrumented system used to implement one or more safety instrumented functions. An SIS is composed of any combination of sensor (s), logic solver (s), and final elements(s). The relation between IEC 61508 and IEC 61511 is shown in the figure below: IEC 61508 is to be used by manufacturers of equipment for use in SIS. IEC 61511 is to be used by SIS system integrators and end-users. In other words, the products are designed using IEC 61508 while IEC 61511 has requirements on how to identify, specify, design, integrate, install, commission, operate, maintain and repair SIS systems. 1.2 Limited Variable Language IEC 61511-1, section 3.2.81.1.2: Limited variability language (LVL): this type of language is designed to be comprehensible to process sector users, and provides the capability to combine predefined, application specific, library functions to implement the safety requirements specifications. An LVL provides a close functional correspondence with the functions required to achieve the application. The intention of LVL is to be simple. To quote US department of Energy, STD-1195-2011: LVL is designed to be comprehensible to process sector users, and provides highlevel configurable program instructions. An LVL would allow the combination of a set of proven functions in limited proven variety of combinations to implement an application (DOE 2011). Commonly used LVLs are ladder diagram, function block diagram, structured text, instruction lists and sequential function charts. These languages can be used together and can be connected to each other. The main idea is to limit the developers choice of solutions and thus limit the opportunities for coding errors. As a consequence of the simplicity of LVLs, the basic skills can be learned relatively quickly. Instruction lists look like assembler programming while structured text looks a lot like Pascal and uses many of the same reserved words such as IF and ELSE. Ladder diagrams and function block diagrams are based on electrical wiring diagrams. Sequential function charts is a graphical language consisting of steps associated with actions (Bruggink 1999). The problem with any programming language, including LVL, is not the complexity of the code but the volume. It is thus possible to end up in problems related to overview and understanding using LVL, just as when using any other programing language. Structured text is best suited for people who already have some programming background. It looks like high level languages such as Pascal, as the example below shows (Bruggink 1999). IF Speed1 > 100.0 THEN Flow_rate := 50.0 + Offset_A1 ELSE Flow_rate := 100.0; Steam := ON END_IF; Figure 1: Relationship between IEC 61511 and IEC 61508 Instruction lists mirror, at least partly, the instructions an operator gets from training or a manual. Instruction lists have a lot in common with assembler language see example below (Bruggink 1999). Note that JMPC means that we will only jump to RESET if R1 is 1 (TRUE)

LD R1 JMPC RESET LD Pressinfo ST Max_Press RESET: LD 0 ST A_X43 Ladder logic is close to circuit diagrams. It uses contacts indicated in the symbols marked as A and B in the diagram below. The example below (ISA.org 2015) show contacts that are normally open. The symbol - / - is a contact that is normally closed. There are also state change sensing contacts, e.g., - P - will close if the correpsondnig variable is changed from OFF to ON. Figure 2: Simple example of ladder logic In figure 2, a lamp will light up if switch A or switch B is closed. The term function block diagram is used for PLC programs described in terms of graphical blocks. It is described as being a graphical language for depicting signal and data flows through blocks, these being reusable software elements. A function block is a program instruction unit which, when executed, yields one or more output values (DOE 2011). The diagram consists of functional units (blocks) and logical gates AND, OR, NAND, etc. components: steps and transitions. A transition from one step to the next will take place when the transition conditions are fulfilled. In the example below (Bruggink 1999) the transitions are marked with T1 and TN. Figure 4: Sequential function chart 1.3 SafeScrum The adaptation of Scrum to the development of safetycritical systems, which we call SafeScrum, is motivated by the need to make it possible to use methods that are flexible with respect to planning, documentation and specification while still being acceptable to IEC 61511, as well as making Scrum a practically useful approach for developing safetycritical systems. The IEC 61511 standard does intentionally not include topics such as project management, project organization, communication and certification. An agile approach to these topics can help the development process. The rest of this section explains the concepts of this combined approach. The SafeScrum model has taken into account some requirements should be outside an agile approach (separation of concern) and some safety requirements have to be added to the agile methods. Most of the development projects last for several months to several years so we have also included information related to the number of Sprints performed. Separation of Concern (SoC) makes an agile approach possible without overloading it with large amounts of nonagile activities: The software developers develop software in SafeScrum. High level planning, systems design and decisions concerning safety are done outside the SafeScrum process. This is named Separation of Concern, see figures 5 and 6 below. Figure 3: Function block diagram A valve is to be operated to lift a load when a pump is running and either the lift switch is operated or a switch operated indicating that the load has not already been lifted and is at the bottom of its lilt channel. A sequential function chart looks a lot like the traditional flow charts. Many of the concepts are the same as in the UML state charts. The sequential functional chart has two main Figure 5: SafeScrum and Separation of Concern

Changes of high-level plans may be fed back from the RAMS validation to the SafeScrum after each sprint. In a Sprint, normally the clauses 12.45 to 12.5 are included (figure 3). Due to the focus on safety requirements, we use two related product backlogs, one functional product backlog, which is typical for Scrum projects, and one safety product backlog, to handle safety requirements. We will keep track of how each item in the functional product backlog relates to the items in the safety product backlog, i.e. which safety requirements that are affected by which functional requirements. Figure 6: V-model, SafeScrum and separation of concern Add-ons are necessary in the sprint as shown in the figure below. Figure 7: SafeScrum and the Sprint The safety requirements and other requirements are documented as product backlogs. A product backlog lists all functional and safety related system requirements, prioritized according to their importance. The safety requirements are quite stable (relevant regulations and safety standards are normally stable during the project), while the functional requirements can change considerably over time. Development with a high probability of changes to requirements will favour an agile approach. Nearly all risk and safety analyses on the system level are done outside the SafeScrum process, but we have developed an approach for safety analysis based on user stories (Stålhane 2015). Software is considered during the initial risk analysis and all later analysis. Figure 8: SafeScrum and several Sprints The core of the SafeScrum process is the repeated sprints. Each sprint can be a mini-waterfall project or a mini V-model, and consists of planning, development, testing, and verification. For the development of safety critical systems, traceability between system/code and backlog items, both functional requirements and safety requirements, is needed. The documentation and maintenance of trace information is introduced as a separate activity in each sprint. In order to be performed in an efficient manner, traceability requires, in practice the use of a supporting tool. The sprint starts with the selection of the prioritized items from the product backlog. The staffing of the development team and the duration of the sprint, together with the estimates of each item, decides which items that can be selected for development. The selected items constitute the sprint backlog, which ideally should not be changed during the sprint. The development phase of the sprint is based on developers selecting items from the sprint backlog, and producing code to address the items. A sprint should always produce an increment, which is a piece of the final system, for example executable code. The sprint ends by demonstrating and validating the outcome to assess whether it meets the items in the sprint backlog. Some items may be found to be completed and can be checked out while others may need further refinement in a later sprint and goes back into the backlog. To make SafeScrum conform to IEC 61511, we propose that the final validation in each iteration is done both as a validation of the functional requirements and as a RAMS validation, to address specific safety issues. If we discover deviations from the relevant standards or confusions, the assessor/authority should be involved as quickly as possible. Running such an iterative and incremental approach means that the development project can be continuously re-planned based on the most recent experience with the growing product.

As the final step, when all the sprints are completed, a final RAMS validation will be performed. Given that most of the developed system has been incrementally validated during the sprints, we expect the final RAMS validation to be less extensive than when using other development paradigms. This will also help us to reduce the time and cost needed for certification. The key benefits of this combination of a safety-oriented approach and a process model for agile software development are that the process enables: Continuous communication between customers, the development team and the test team(s). Re-planning based on the most recent understanding of the requirements and the system under development. Mapping of functional and safety requirements. Coordination of work and responsibilities between the three key roles; the development team, the customer and the assessor/authorities. All of these points will help us to get a more transparent process and thus better control over the development process. 2 IEC 61511-1 REQUIREMENTS ASSESSMENT One of the most important concepts when using SafeScrum is the separation of concerns (SoC) what will be taken care of in the SafeScrum process and what is outside this process. In this way we separate the standard s requirements for software development from the rest of the requirements in the standard and keep the good parts of the Waterfall approach. To check possible challenges when adapting SafeScrum for IEC 61511-1 compliant software, we have done a detailed study of parts 5 7, 12, 15 and 19 of the standard. The other sections have been left out for now as they are considered as SoC (upfront activities and activities performed after the last code has been written and tested) or already taken care of - e.g. safety requirements traceability. In addition, we have left out all discussion related to the use of ISO 9001 and the application of change impact analysis since these activities have been described elsewhere see Stålhane (2008), Stålhane (2014-1), Stålhane (2014-2) and Myklebust (2014-1). In addition we have, in an earlier paper, discussed problems related to documentation in agile development see Myklebust (2014-2). Further we will present a paper (Stålhane 2015) at SafeComp/SASSUR discussing the configuration management issues. This discussion will not be repeated here. After a thorough walk-through, we are left with the following sections of the standard which will be discussed in more details below: Section 5: Section 5.2.4 safety planning Section 6: Section 6.2.1 define life-cycle Section 7: Verification Section 12: Section 12.1.2.6 earlier life-cycle, 12.1.2.8 test planning Section 15: Validation Section 5.2.4: A safety plan shall be established. The first issue can be a high level plan. Details can be included as part of the sprint planning. The backlog should also be up to date according to (Kniberg 2007) as he states "Make sure the product backlog is in shipshape before the sprint planning meeting". The standard requires that these plans shall be maintained throughout the development life cycle. This activity has to be inserted into e.g. the SafeScrum as part of the sprint planning activity. An Agile safety plan should among other things normally include a description of the method used as e.g. SafeScrum and plan the incremental development. The requirement for the safety plan has not been changed in the draft 2014 edition of IEC 61511. Section 6.2.1: define life-cycle. The standard requires that safety life-cycle incorporating the requirements of this standard shall be defined during safety planning. This has been thoroughly discussed in (Stålhane 2008). Important issues such as the definition of the life-cycle model and entryand exit-criteria for each activity are a natural part of agile development. The results presented on documentation in agile development of safety critical software in Myklebust (2014) are also important here. This activity has been discussed with our industrial partners and is easy to add to the SafeScrum process. The corresponding requirement in the draft 2014 edition of IEC 61511 has not been changed. Section 7: Describes the requirements for software verifications. Which verifications shall be performed for each Sprint has to be considered and whether a Sprint including only verifications shall be performed. This verification chapter is weak in the current edition of IEC 61511 but has been improved in the draft version IEC 61511:2014. The improvements in the draft version do not have a negative impact on SafeScrum. Section 12.1.2.6: The standard requires us to go back to an appropriate phase in case of a change. It is, however, up to the project manager to decide what the appropriate phase is. Traceability and configuration management information will help in deciding this. The corresponding requirement in the draft 2014 edition of IEC 61511 has not been changed. Section 15: This chapter includes requirements for validation. Parts of the validation, e.g. testing, can be performed as part of sprints while other parts of the validation plan have to be performed after the last sprint but before the release. Demonstration shall be performed such that functional performance and safety requirements are met. The responsibility should lie with the RAMS activity after each sprint. The corresponding requirement in the draft 2014 edition of IEC 61511 has not been changed. Another important question is whether the use of LVL is suitable for the SafeScrum method? Yes, the SafeScrum method can be used as described in section 2. When using LVL, the software language limits the flexibility related to functions and applications. And when using LVL it is not required to include all the techniques and measures presented in Annex A and B in IEC 61508. The use of e.g. ladder logic even supports the quick feedback that is one of the cornerstones of Agile methods. Just a quick glance at a ladder program lets you know what is e.g. on and what is off. This kind of feedback is undoubtedly the major advantage of using ladder logic. Ladder logic places the information you need where it is needed.

REFERENCES 1. Stålhane, T., Myklebust, T., and Hanssen, G.K. 2012. The application of Safe Scrum to IEC 61508 certifiable software. ESREL 2012, Helsinki, Finland. 2. T. Stålhane, V. Katta and T. Myklebust. Scrum and IEC 60880. Presented at the yearly IFE conference March 2013. 3. Fitzgerald et al. 2013 - Scaling Agile Methods to Regulated Environments: An Industry Case Study. 4. F. Redmill. Agile methods for developing safety-related software? SCSC Newsletter September 2014. 5. DOE-STD-1195 2011. Design of Safety Significant Safety Instrumented Systems used at DOE Nonreactor Nuclear Facilities. US Dep. of Energy, Washington DC 6. T. Stålhane and T. Myklebust. Agile Safety Analysis XP 2015. Helsinki Finland. 2015 7. M. Bruggink. Programming PLCs using Sequential Function Chart. Department of Computer Science, Nijmegen, The Netherlands, January, 1999 8. https://www.isa.org/pdfs/basic-ladder-logicprogramming-chapter2/. Evaluated May 2015. 9. T. Stålhane and G. K. Hanssen. 2008. The application of ISO 9001 to agile software development. 10. T. Stålhane, G. K. Hanssen, T. Myklebust and B. Haugset. Agile change impact analysis of safety critical software. SafeComp_Sassur, 2014 11. T. Stålhane, V. Katta and T. Myklebust. Change Impact Analysis in Agile Development. EHPG Røros 2014 12. T. Myklebust, T. Stålhane, G. K. Hanssen and B. Haugset. Change Impact Analysis as required by safety standards, what to do? PSAM 12 Hawaii 2014 13. T. Myklebust, T. Stålhane, G. K. Hanssen, T. Wien and B. Haugset. Scrum, documentation and the IEC 61508-3:2010 software standard. PSAM 12 Hawaii 2014 14. H. Kniberg. Scrum and XP from the Trenches, How we do Scrum. InfoQ 2007 System Safety, SINTEF ICT Norway. e-mail: thor.myklebust@sintef.no He has an MSc in Physics. In addition he has two years of education within economy, psychology and statistics at the University level. His experience in certification of products and systems since 1987. Myklebust has participated in several international committees since 1988. Member of safety (NEK/IEC 65), IEC 61508-3 committee, railway (NEK/CENELEC/TC 9) and NBrail (notified bodies) since 2007. Chairman of NB-rail since October 2014. Founder of SafeScrum. Tor Stålhane; PhD and Professor Emeritus Department of Computer and Information Science, Norwegian University of Science and Technology (NTNU) e-mail: stalhane@idi.ntnu.no He has a PhD in statistics from the Norwegian University of Science and Technology (NTNU). He has experience in software engineering topics such as software process improvement, reliability assessment, quality assurance and cost estimation. His current area of interest is safety analysis of software intensive systems. Founder of SafeScrum. Narve Lyngby; System Safety, SINTEF ICT Norway. e-mail: narve.lyngby@sintef.no He holds a position as senior advisor at SINTEF ICT and has wide experience as senior project manager both from railway and offshore projects from his previous employers. Member of NB-rail since 2012. He is currently about to finish his PhD degree within the field of Maintenance- and safety management within railway industry at the Norwegian University of Science and Technology, NTNU in Trondheim. BIOGRAPHIES Thor Myklebust; Certification manager, Cand. Scient. Physics.