In the design process of AGVs and robotic arms, safety circuits such as emergency stop, enable, protective stop, speed control, and safety door lock are usually added to meet CR, CE or customer requirements. When designing these circuits, some companies choose safety PLCs from Schneider, Sick or Siemens and may carry out secondary development. Some companies will use chips such as DSP, ARM, FPGA to develop their own safety control boards or drivers.
This brings us to a common problem in the industry: many third parties only assess whether the hardware meets PL (PL calculation) requirements, neglecting the software. This approach carries significant risk, easily leading to scrutiny from owners or other third-party organizations, and ultimately, failure to meet specific requirements. Whether it's secondary development application software or embedded software, the software security of the core control logic of the safety loop is paramount. This article will introduce key points to consider during software development.
It's important to clarify why the development of safety software must meet specific requirements. Can it be developed using the usual enterprise development process? As we all know, regardless of the language, model, algorithm, or developer, software inevitably contains many bugs. These bugs, under certain conditions, can cause errors in software operation, also known as systemic failures. For non-safety applications, timely fixing is sufficient. However, for safety applications, these bugs can prevent safety functions from executing or cause malfunctions, potentially leading to accidents such as personal injury or death. Therefore, the development of safety-related software must be extremely cautious. The specific requirements in relevant safety standards are actually aimed at the software development process, with the goal of minimizing bugs in the software to improve the safety of AGVs and robots. The following will detail some key points for your understanding.
First, the selection of applicable standards
For secondary development application software, if the client or technical standards require a certain Level of Process Control (PL), the software development should follow the application software requirements in Section 4.6 of ISO 13849-1-2015. For embedded software, if the PL requirement is between a and d, then the embedded software development requirements in Section 4.6 of ISO 13849-1-2015 should be followed; if the PL requirement is e, then the requirements of IEC 61508-3 must be followed. Furthermore, for safety control boards or modules, which can be sold as standalone products or used in multiple product series, it is generally recommended that they meet the standards of IEC 61508, ISO 13849, and IEC 62061.
Second, the selection of development models
Currently, commonly used development models in the industry include the V-model, Waterfall model, Agile development model, and Spiral development model. However, security software development tends to be conservative, prioritizing secure and reliable software over development efficiency. Therefore, IEC 61508, ISO 13849, and IEC 62061 all require the use of the V-model in development. The biggest benefit of the V-model is the early involvement of testing. It requires test engineers to participate in reviewing requirements, architecture design, and detailed design documents, and simultaneously design test cases and edit test specifications. The aim is to identify defects in requirements or designs in a timely manner through the participation of testers, improving the rationality of requirements or designs. However, the V-model also has a major problem: iteration. If testing discovers a bug or subsequent changes are made, the design must revert to the corresponding stage on the left side of the V-model and be re-executed according to the V-model, which introduces a significant workload for developers.
▲Figure 1 V-model for software development
Third, the choice of development tools
Regarding the selection of development tools, the general requirement for functional safety is that development tools must be certified during the development process. Certification can be categorized into three types: first, for application software, development tools provided by the PLC vendor can be used; second, proven development tools, meaning tools widely used in the industry or similar product development; and third, tools that have undergone functional safety certification, meaning they have been certified by a specific third-party organization. For example, C++test has passed T2-class tool certification, and Cantata is also certified. Furthermore, it is necessary to verify the version, user manual, and precautions of the development tools, and to compile a tool certification report. Additionally, it is important to note that online software testing tools must adhere to the same PL or SIL requirements as the software itself during development.
▲Figure 2: Requirements and explanations for tools in IEC 61508 standard
Fourth, the choice of development language and programming guidelines
Currently, commonly used software development languages are divided into finitely variable languages and fully variable languages. Finitely variable languages refer to languages such as ladder diagrams, function block diagrams, and sequential function charts, while fully variable languages refer to languages such as C, C++, and C#. Finitely variable languages are commonly used in application software development, while fully variable languages are commonly used in embedded software development. The language requirements in the IEC 61508 standard are shown in Figure 3. It should be noted that although ADA, PASCAL, and Modul2 are strongly recommended by SIL1 and SIL2 standards, they are now almost unused due to their age. In embedded software development, the C-series languages are currently the most commonly used.
▲Figure 3 Selection of software development language
Furthermore, when programming using the aforementioned languages, the functional safety standards also require adherence to programming guidelines. The following links provide recommended programming standards, and Figures 4, 5, and 6 illustrate the coding guidelines required by the standards. In practice, software engineers are generally advised to adopt these guidelines and perform static rule checks or code reviews in accordance with them.
Examples of programming standards
http://www.misra.org.uk/
http://java.sun.com/docs/codeconv/index.html
http://www.gnu.org/prep/standards/
▲Programming requirements in ISO 13849 (Figure 4)
▲Figure 5 General requirements for programming languages in IEC 61508
▲Figure 6 IEC61508 Object-Oriented Programming Requirements
Fifth, the use of open-source code.
Open-source code is an unavoidable issue in software development. It's well known that many companies use a large amount of open-source code to reduce workload, save labor costs, and improve development efficiency. Some of this code is provided by software development libraries, while some is collected from the internet. This code poses significant risks in functional safety software development. The biggest risk lies in the fact that the code may not have adhered to functional safety development processes and requirements, potentially containing numerous unknown bugs that could lead to safety function failures. However, the IEC 61508 functional safety standard does not completely exclude the use of open-source code. The standard provides three approaches: first, using source code developed entirely according to functional safety requirements, which requires proof; second, using proven open-source code, meaning providing classic examples of its use in similar products and conducting additional analysis; and third, formally evaluating the development process of the open-source code, meaning the users need to provide design documents for the entire development process.
In addition, there's a shortcut I can share: developers can rewrite and test the open-source code according to functional safety requirements, based on the code's logic. This can save a lot of work.
