There is an ongoing trend involving a switch from automated systems operating in isolation from users with barriers and protection (such as isolated metro systems) to an arrangement where systems are integrated into operations close to the users, e.g. autonomous vehicles and drones used for air transport (Guiochet et al., 2017). Alternatively, operational functions may be relocated and centralised further away from the production process that is being controlled. The increasing introduction of automation and autonomous operations via robots will require appropriate
procedures and standards during the development of solutions and appropriate procedures for risk assessments and operational procedures. We have therefore listed some guidelines relating to development, followed by a list of relevant standards and practice memos which describe a framework for risk assessments and standards for operational activities.
7.5.1 Standards for the development of solutions
The starting point for the development of standards is based on having a specification of
requirements which describe the system as a whole, i.e. from a system perspective as described in Figure 1.1, with a description of the interface with users, necessary support from infrastructure, interfaces with other autonomous systems and interfaces with control systems (if necessary).
Concept development can often entail radical innovation, but should address the interface/contact with users, as outlined above, e.g. via IEA/ILO (2020) or ISO 11064, to ensure that the principles of
"Fitts list" (De Winter et al., 2014) are safeguarded, i.e. ensuring that human limitations and opportunities are addressed.
The development of software for automated systems and autonomous systems also requires methods and standards, ranging from “waterfall standards” to standards for agile development.
Methods for the introduction of systems depend on whether readymade package solutions are to be used or whether programming and inhouse development are necessary. Standards, guidelines and development methods should be established in all development projects which include analysis, development, testing and the establishment of appropriate routines and procedures. For the development of critical systems and programming of automated systems, it is most important to point out that standards, guidelines and methods must be established. However, we believe that it is important to mention agile development as an important contribution to the rapid development of high-quality systems. This has become increasingly important in recent years, as systems have to be
“patched” more rapidly and more frequently, partly as a result of security challenges.
Iterative and incremental software development which is an important part of agile development began back in the 1950s. Agile development was placed on the agenda in 2001 through the "agile manifesto" (Beck et al., 2001). Initially, agile development was only used in the development of general software and is now used worldwide. The methodology is so effective that it is also used in the development of instrumented safety systems in other industries.
In 2011, SINTEF and NTNU began the development of SafeScrum (Hanssen et al., 2018), which is used in the development of critical software and instrumented security systems. Both agile software
Section 33a Control and monitoring systems EN 62682, EEMUA 191 and YA710
development and SafeScrum involve the customer (operators, etc.) to a greater extent than is the case with normal software development. One of the principles of agile development establishes the following principle: "Our highest priority is to satisfy the customer through early and continuous deliveries of software which has value". SafeScrum and other similar approaches have become increasingly popular within all security domains. Agile methods are now being used by most suppliers to a greater or lesser extent. SINTEF sent an enquiry to all relevant certification bodies that the Norwegian supply industry uses regarding SafeScrum. These certification bodies responded that they accept SafeScrum as a development process. In most projects, aspects of the safety life- cycle (e.g. “Waterfall” and “V model”) are combined with SafeScrum or other similar approaches.
In IEC 61508, the committee switched from being somewhat sceptical towards agile methods in 2014 to the view that agile methods are acceptable. Greater account of this is taken in the next version of the standard. SafeScrum is also permitted in relation to the current version of the IEC 61508 standard. It is of course necessary to satisfy all applicable requirements and perform all relevant analyses even when using agile methods. Documentation has long been a challenge both in general and within the petroleum industry in particular, not least when developing security-critical software. SINTEF and NTNU have therefore developed an agile approach to documentation by developing a methodology for "agile documentation" to confirm that products/systems are safe (Myklebust et al., 2018).
The most important requirement in connection with the development of automated and autonomous systems is that there is a standard method which defines requirements regarding how the
development should take place, and how testing, documentation and procedures for use should be addressed. The need for certification, quality assurance and approval of the system should be clarified.
7.5.2 Standards for the risk assessment of automated systems (including robotisation) The systematic risk assessment of equipment and new technology forms an integral part of the regulations, but it is still important to highlight existing and new standards that should be applied.
Moreover, we also believe it is necessary to refer to good practice for the use of autonomous
systems, and, in this context, refer to a standard for the use of autonomous systems in mining which lists the practice of risk assessments and operations (Bolsin, 2018; Department of Mines and
Petroleum (2015).
Relevant standards for the risk assessment of automated/autonomous systems (and robots) must be based on the Machinery Regulation (the Regulation on Machinery) of 20 May 2009.
A hierarchy for safety standards which define the necessary guidelines (and good practice) for robotisation is listed below, from the general to the more specific:
Table 7.3 Hierarchical overview - safety standards and good practice for robotisation
Standard Remarks
Overarching standard – see also ISO/DTR 22100- 5:2020 “Safety of machinery — Relationship with ISO 12100 — Part 5: Implications of embedded Artificial Intelligence-machine learning" (AI introduces greater uncertainty)
Consider various "hazards", award scores, can they be prevented, discuss consequences, etc.
Use of robots in industrial contexts— Part 1:
Robots; — Part 2: Robot systems and integration The standard lists and discusses safety features that may be of relevance
Standards - security for safety
NOROG -104 Recommended guidelines and requirements regarding information security levels in IT-based process control, security and support systems
Overarching guidelines for safety (and security), developed in cooperation in the petroleum sector, based on Johnsen et al (2008).
Important for security for control systems and describes, amongst other things, certification schemes that should be implemented. (The standard is recommended for use in the petroleum sector in Norway).
May be relevant, but does not discuss physical contact between equipment and user. The machine-specific variant is IEC 62061.
7.5.3 Summary of key standards that should be given more attention
Key recognised standards relating to interaction design for control systems that should be incorporated into the regulations are as follows:
• The ISO 9241 series: Alarm management is a vital prerequisite for managing complex operations, and best practice within alarm management should be followed up via EEMUA 191, for example.
Good practice for risk assessment and safety should be applied. The standards that address this area are:
The securing of infrastructure and systems should be addressed via the IEC 62443 standard and the certification schemes it recommends based on framework conditions provided by NOROG 104.
A gap between actual practice and HF standards was highlighted during the interviews. User-centred design and meaningful human control should be applied as principles in connection with the introduction of automation where the human still has an important role to play, and the framework surrounding this is described in
8 Workshop – automated systems and human factors
We held a workshop with 20 participants from PSA, SINTEF and the industry on 29 and 30 September, in order to validate and discuss findings (from the report – especially the literature review, interviews and investigations) and review the relevance of measures. Through this workshop, we wanted to both identify common attitudes and build a greater understanding of findings. We also wanted to identify proposals for measures that the stakeholders could agree on and where the findings can be implemented (i.e. a reality check that it is possible.)
In the following, we describe findings and measures relating to the areas that were discussed over the two days:
Day 1: Human factors associated with development in four areas: Balance between technological focus and human factors; Use of standards that address human factors; Fragmented structure for development; Updated regulations.
Day 2: Human factors during investigations in four areas: Breadth of investigation; Design assessments in investigation; Successful incidents; Near misses.