To main content

An agile development process for petrochemical safety conformant software


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 (Stalhane 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 - dd 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 (Stalhane 2012) and IEC 60880 (Stalhane 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.


Academic article





  • SINTEF Digital / Software Engineering, Safety and Security
  • Norwegian University of Science and Technology



Published in

Proceedings. Annual Reliability and Maintainability Symposium (RAMS)




IEEE (Institute of Electrical and Electronics Engineers)

View this publication at Cristin