EN 
DE Model-based development of high-integrity robots
Authors: Dipl.-Ing. Maximilian Apfelbeck and Dr.-Ing. Stephan Myschik, The MathWorks GmbH, Ismaning
Contribution – Embedded Software Engineering Congress 2015
In the future, the proportion of robots interacting with humans will increase rapidly. They are equipped with a large number of sensors to perceive the dynamic environment. The sensor data is evaluated and fed into algorithms that ensure safe collaboration and response from the robot. The algorithms used must also comply with safety standards such as IEC 61508-3. [1] They are being developed. One way to meet these standards is model-based development. This is already being used very successfully in the automotive industry, among others. This presentation will discuss a procedure for the verification and validation of IEC 61508-3 compliant software components of collaborative robots using an example.
Introduction
„A robot may not injure a human being…“ is the first of Asimov’s Laws [2]. To ensure this law is not violated, a very large percentage of robots of varying sizes are currently separated from humans by fences or light barriers. However, this separation must be replaced by other safety mechanisms so that new applications and areas of use for robots, especially in human-robot interaction, become possible. Examples of new applications include the use of robots as production assistants [3] or in the care of people in need.
There are various technical solutions to ensure safety in human-robot interaction. This can be achieved, for example, through mechatronic design. One approach is to limit the robot's dynamic range so that no injury to a person is possible upon contact [4]. Other options include incorporating mechanical clamps that slip under overload or using serial elastic actuators [5]. With mechanical clamps, slippage prevents potentially dangerous human-robot contact. However, this solution is rarely applicable because it would require recalibrating the entire system. Another approach is to use software and monitor sensors; this can be implemented with minimal effort. For this purpose, the robot is equipped with an intelligent, sensitive skin that stops the robot in the event of unexpected or high-energy contact [6]. In cases where a tool, such as a screwdriver, is potentially hazardous to humans, more sophisticated algorithms are required. One possible solution is presented in [7]. A key argument for using such monitoring and security software is the unit cost. This decreases with the number of end products. However, before it can be used in a finished product, it must be proven that it is error-free and developed in accordance with safety standards.
Model-based development can support the development of control algorithms or monitoring logic for these safety-relevant applications. Verification and validation concepts for demonstrating the correctly implemented functionality with regard to requirements or standards are integral parts of the model-based development methodology.
The first part of this publication demonstrates the model-based development approach using a robot as an example. The second part discusses verification and validation steps to ensure that the resulting software component conforms to the IEC 61508-3 standard. Finally, application examples from the aerospace and medical technology sectors are presented to illustrate the successful use of this development process.
Model-based development along the V-model
The following uses the V-model [8], see Figure 1 (PDFThe development of safety-relevant algorithms for robots is explained. A development process based on the V-model is widely used. The robot used is shown as a CAD model in Figure 2. The goal is to develop "pick and place" applications for the robot. It should be possible for a person to be within the robot's workspace.
In addition to the overarching task of performing "pick and place" operations, technical requirements such as maximum performance, installation space, and repeatability, as well as safety-related requirements, are defined in the requirements document. These requirements are increasingly stored in a requirements management system. A possible requirement to ensure safe human-robot collaboration could be the following:
- REQ XY: The robot must stop its movement in any configuration within x.x seconds in a potentially hazardous situation. A hazard is present when the joint torque in any axis y% or z Nm exceeds the required torque.
This situation can occur, for example, in the case of contact with objects or people during operation.
Based on the requirements document and the system to be developed, the first step in model-based development is to define the system architecture. This involves segmenting the system into different units and defining the interfaces between the components. A robot can be divided into software and hardware. The software can be decomposed into monitoring logic, coordinating controllers, and joint controllers; the hardware into mechanics and electronics. This approach is illustrated in Figure 3 (see PDF) and was displayed in Simulink® implemented.
The requirements are linked bidirectionally to the respective components for optimal tracking. In the further development process, the individual components are then functionally developed and modeled according to the interpretation of the requirements. One advantage of Simulink.® The key is that the components, and therefore the requirements, are feasible. This gives the engineer immediate feedback on the quality of their design. They can identify errors early in the development process and thus significantly minimize project risk.
The creation of individual model components is supported very efficiently by specially adapted tools. The mechanics can be derived from CAD assemblies into a multibody system consisting of joints and individual bodies. CAD import into SimMechanics™ thus ensures that the correct component parameters, such as mass, center of gravity, and center of gravity position, are used in the simulation. Furthermore, the graphical representation of the individual components is also included. This approach can significantly accelerate the modeling of the mechanical system [9]. Figure 2 (see PDFFigure 4 shows the graphical representation of the imported assembly. The imported system can also be used as a starting point for kinematic optimization or actuator design. In addition to the motors, other physical components (gears) or effects relevant to control (friction, backlash, stiffness) can be easily linked to multibody mechanics. This is shown in Figure 4 (see Figure 4). PDF) shown. The parameterization of these components can often be found in datasheets.
Simulink is best suited for modeling the controllers.®; for the Stateflow monitoring logic®, see Figure 5 (see PDF).
Once the physical path and the first software component have been modeled, initial virtual tests of the overall system can be performed. In small iterative steps, more and more intelligence and functionality are added to the software and continuously tested. With each simulation run, the current model is validated and verified against the requirements. Additionally, optimal parameterization of the software component can be determined in the simulation. Figure 5 shows the result of the step response of an optimized PID controller for a robot joint.
Advantages of model-based development methodology:
- Representing an entire system with models increases the comprehensibility of the created systems and improves communication between the individual engineering disciplines within a company.
- Using a development environment reduces the effort required to convert data and information between different software tools.
- Simulating the entire system in early phases helps considerably to find and correct errors in very early stages.
The following NASA study [10] confirms the importance of finding errors in early development stages. The later an error is found within a project, the more expensive it becomes to correct it.
Once the software design has been fully developed at the model level and compliance with the requirements has been demonstrated, production code can be generated from the model using the Embedded Coder. This is prequalified by TÜV Süd for software development for IEC 61508-3 compliant code [11].
Verification and validation of the model and generated code
The following questions in software verification and validation can be answered positively in model-based development [12]:
- Are the textual requirements correctly implemented in the model?
- Does the object code, which is later used on the robot, correctly reflect the behavior of the model?
MathWorks has developed a reference workflow [13] that helps answer both questions. This involves dividing development into the design verification and code verification phases.
Design verification
The goal of this phase is to prove that the model meets the requirements and does not contain any unwanted functionality. This is demonstrated through both static analysis and functional testing. Static analysis examines the model for constructs that are, for example, suboptimal for code generation. Furthermore, predefined or custom modeling guidelines can be verified. Models that are transferred to production code can also be tested for compliance with safety standards. Figure 6 (see PDFThis report shows the result of the verification of a model component according to "Modeling Standards for IEC 61508". It assists in identifying modeling errors, correcting them, and documenting successful testing. A model checksum allows the report to be uniquely assigned to a specific system and model version.
Once the modeling guidelines have been successfully verified, a coverage analysis of the model is performed. The goal is to uncover unwanted functionality or missing requirements. A possible example for the robot shown in Section 2 is calculating a correct result for the inverse kinematics. The calculated joint angles must always lie within the joint limits. This can be achieved, for example, by the method shown in Figure 7 (see PDFThe construct shown can be proven.
To demonstrate the functional correctness of the inverse kinematics, the result checks must be fulfilled. Figure 8 (see PDF) indicates a violation of these checks due to a faulty implementation.
Furthermore, complete model coverage of the inverse kinematics must also be available. The result of the analysis of a specific test case is shown in Figure 9 (see PDFThis shows that certain areas of the inverse kinematics are not executed. Therefore, this test cannot prove the functional correctness of specific model components. All tests can be performed and documented automatically. In addition to these functional tests, it is also possible to automatically derive test vectors.
After all static and functional tests have been successfully completed and complete coverage of the requirements by the model has been proven, code is automatically generated from the model. Figure 10 (see PDFFigure 1 schematically illustrates the code generation process. The code derived from the validated model can now be transferred to the target platform. The code generation process produces a report that facilitates traceability from requirements to the model and then to the code.
Code verification
To fully validate the algorithm, it must be proven that there is no functional difference between the model and the object code. For this purpose, the model and object code are stimulated with identical test vectors. The object code is executed directly on the target platform. Embedded Coder offers "Processor-in-the-Loop" (PIL) simulation for this purpose. This is shown in Figure 11 (see PDF) shown.
The simulation results of the verified model are stored as expected values alongside the test vectors. In PIL simulation, the object code is transferred to the target platform via a debug interface, such as JTAG. The Simulink model transferred to the processor is executed in PIL mode. Communication between the robot model running in Simulink and the controller on the target platform is established via the serial interface or TCP/IP.
Correct functionality of the object code is proven when there is a sufficiently good agreement between the two simulations (verified model and PIL). Influences from different compilers or floating-point units can cause discrepancies between the simulation and the object code. In addition to demonstrating functional equivalence, it must also be proven that no unwanted functionality was introduced during code generation. This can be shown by comparing the coverage at the model and code levels and by verifying traceability, which the Embedded Coder® supports through automatic documentation. A traceability report is shown in Figure 12 (see PDF) shown. This report contains the complete mapping of the model to the code and a list of model components that are missing from the generated code due to code optimization. A bidirectional link from the model to the code, as well as links to the requirements, are also documented, see Figure 13 (PDF).
Industrial applications
The two preceding sections describe a possible approach to generating certifiable software using model-based development. This process is used in whole or in part by many companies across a wide range of industries. Weinmann [15] uses parts of the described development process to develop software for new transport ventilators. For this product, the complexity of the algorithms is many times greater than in the past. In addition to the algorithms, the functionality of the human lung and the ventilator was also modeled. This made it possible to pre-calculate the entire system, consisting of software, device, and user, and to evaluate and test a large number of different design alternatives. This was not possible with their conventional development methodology. Before production code was generated, the algorithms also had to pass coverage tests at the model level. The switch to model-based development accelerated the development process at Weinmann, making certification for safety-critical systems much faster. Furthermore, the modeled systems are reused in many future projects.
By using model-based development, Eurocopter accelerates the development of DO-178B certified software [16]. The main challenge was that design flaws were introduced through misinterpretation of requirements or incorrect implementation of systems that behaved correctly but not as intended. Eurocopter estimates that approximately 90% of the problems found late in the project were introduced by errors in the specification or design phase. The number of errors was significantly reduced by the introduction of model-based development due to early testing and continuous verification and validation.
The created models are analyzed for compliance with modeling guidelines for DO-178B compliance using model standard checks and model coverage. After successful verification, the automatically generated code is compiled into object code. This is then tested against existing test vectors. This process supports Eurocopter in automatically generating code that is subsequently certified for the EASA DO-178B standard. This approach has reduced software testing time by two-thirds, and requirements could be finalized much earlier. Compared to similar projects, these requirements are now finalized approximately one year sooner.
Summary
A procedure for creating certified code according to IEC 61508-3 for robotic systems was discussed. Applying this software development process leads to higher software quality, reduced development times, and less effort required for software certification. Furthermore, modeling the algorithms and systems and their graphical representation supports technical communication and system understanding within project teams. Model-based development has the potential to become a key component for future developments of collaborative robots.
References
[1] International Electrotechnical Commission: Functional safety of electrical/electronic/programmable electronic safety related systems – Part 3: Software requirements, IEC 61508-3 ed.2, Geneva, 2010.
[2] Asimov, Isaac: Runaround, 1942.
[3] Robert Bosch GmbH, https://www.bosch-apas.com/en/apas/start/bosch_apas.html.
[4] ABB AG, https://new.abb.com/products/robotics/de/yumi.
[5] Rethink Robotics, https://www.rethinkrobotics.com/baxter/.
[6] MRK Systeme GmbH, https://www.mrk-systeme.de/produkte_interaction.html.
[7] Haddadin, Sami: Towards Safe Robots, Springer Tracts in Advanced Robotics, Vol. 90, 2013.
[8] Friedrich, Jan; Kuhrmann, Marco; Sihling, Marc and Hammerschall, Ulrike: The V-Model XT For project managers and QA managers compact and clear, Springer-Verlag Berlin Heidelberg 2009.
[9] Saneon GmbH, https://www.saneon.de/cms/index.php/en/component/content/article/1-aktuelle-nachrichten/123-simulation-saneon.html.
[10] NASA, Return on Investment for Independent Verification & Validation, 2004.
[11] TÜV SÜD Certificate, Z10 11 12 67052 014.
[12] Conrad, Mirco and Sandmann, Guido: A Verification and Validation Workflow for IEC 61508 Applications, SAE Technical Paper 2009-01-0271, 2009.
[13] The MathWorks, Inc. https://www.mathworks.com/products/iec-61508/.
[14] The MathWorks, Inc. https://www.mathworks.de/products/embedded-coder/.
[15] The MathWorks, Inc. https://www.mathworks.com/tagteam/76574_91946v01_Weinmann_UserStory_final.pdf
[16] The MathWorks, Inc. https://www.mathworks.com/tagteam/77159_92118v00_Eurocopter_UserStory_final.pdf
Our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.
Training & coaching on the other topics in our portfolio can be found here. here.
Quality, Safety & Security – Expertise
Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
