final report of the sams project - dfki gmbh · final report of the sams project ... for software...

35
Safety Component for Autonomous Mobile Service Robots Final Report of the SAMS Project Zusammenfassender Schlussbericht des Projektes SAMS Christoph Lüth This research has been funded by Federal Ministry of Education and Research unter Grant 01 IMF 02. Responsibility for the contents of this report remains solely with the author. Deutsches Forschungszentrum für Künstliche Intelligenz Trippstadter Straße 122 67663 Kaiserslautern Universität Bremen Bibliothekstraße 1 28334 Bremen Leuze electronic GmbH + Co. KG Liebigstraße 4 82256 Fürstenfeldbruck

Upload: vuxuyen

Post on 13-Apr-2018

214 views

Category:

Documents


0 download

TRANSCRIPT

Safety Component forAutonomous Mobile Service Robots

Final Report of the SAMS Project

Zusammenfassender Schlussbericht des Projektes SAMS

Christoph Lüth

This research has been funded by Federal Ministry of Education and Research unter Grant01 IMF 02. Responsibility for the contents of this report remains solely with the author.

Deutsches Forschungszentrum für Künstliche IntelligenzTrippstadter Straße 12267663 Kaiserslautern

Universität BremenBibliothekstraße 128334 Bremen

Leuze electronic GmbH + Co. KGLiebigstraße 482256 Fürstenfeldbruck

Final Report

— ii —

Final Report

Abstract

In the SAMS project (Sicherungskomponente für autonome mobile Servicero-boter, safety component for autonomous mobile service robots), a module for calcu-lating the safety zone of a moving autonomous vehicle or service robot depending onthe current velocity and steering angle was developed, implemented and certified foruse as a safety function up to safety integrity level (SIL) 3. The safety zones coverthe whole area traversed by the robot while braking with the current velocity untilstandstill including safety and error margins as required by norms and standards. Bymonitoring this safety zone with a laser scanner, safety from collisions with staticobstacles can be guaranteed. The results of the projects are summarised as follows:

(i) development of a braking model for autonomous vehicles and mobile ser-vice robots which is simple to configure and a safe, conservative approx-imation;

(ii) development, implementation and verification of an algorithm to calculatevelocity-dependent safety zones which can be used in a safety functionaccording to IEC 61508-3 up to SIL 3;

(iii) development and implementation of a verification environment for thespecification and verification of MISRA-C software according to IEC61508-3 up to SIL 3.

Conformance to IEC 61508-3 was confirmed in writing by TÜV Süd after review.The core of the certification process was the formal mathematical modelling andcorrectness proof in the theorem prover Isabelle, supplemented by additional testswhere required. The techniques developed to this end are not restricted to the partic-ular application domain at hand, but can be reused in other applications.

— iii —

Final Report

— iv —

Final Report

Contents

1 Objectives 1

2 Results 12.1 Conservative Braking Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Algorithm to Compute Safety Zones . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Verification Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Three-dimensional Safety Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Dissemination 83.1 Safety Zones and Verification Environment . . . . . . . . . . . . . . . . . . . . 83.2 Commercial Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Publications and Presentations . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

A List of publications 9

B Letter of conformance for SAMS control software 11

C Letter of conformance for SAMS verification environment 13

D TÜV Technical Report 15

— v —

Final Report

— vi —

Final Report

1 Objectives

The aim of the SAMS project was the development of a verified and certified component for safeservice robotics. The component should evaluate the distance measurements of a laser scannerand reduce the speed of an autonomous mobile robot such as to avoid collisions with obstacles.This principal functionality, called drive way protection (Fahrwegsicherung) is state of the artfor research prototypes and unsafe service robots. However, before this technique can be usedcommercially, it has to be certified by a certification body such as TÜV (in Germany). Thesituation is similar for automated guided vehicles (AGVs) as used in industry, where a certifiedlaser scanner controls a fixed safety zone, initiating an emergency stop of an obstacle is detected.This leads to a lack of flexibility in drive ways and speeds, and prevents an efficient and cost-effective solution.The aims of the project were therefore to develop a certifiable drive way protection for servicerobots and AGVs, where a certified laser scanner monitors a safety zone which is dynamicallyapapted to the current velocity and curve. The main goal was the formal mathematical modellingand proof of correctness of the implementation with a theorem prover; this proof, together withadditional tests as required by the revelant norms and standards, was to be the basis of externalcertification by TÜV.

2 Results

The results of the SAMS project as achieved by the project partners, Leuze electronic, Universityof Bremen and the German Research Centre for Artificial Intelligence (DFKI) can be summarisedas follows:

(1) Development of a braking model for autonomous vehicles and mobile service robots,which is simple to configure and can be proven to be safe;

(2) development and implementation of an algorithm to compute safety zones, whichcan be used in a safety function according to norm IEC 61508-3 up to SIL 3;

(3) a verification environment, which can be used for the specification and verificationof MISRA-C software according to IEC 61508-3 up to SIL 3;

(4) and further to the original project objectives, a generalisation of the safety zones inthree dimensions.

The second and third points were confirmed by TÜV Süd Rail in writing (see Fig. 1) after review;details of the review process can be found in the technical report by TÜV Süd, which can befound in the appendix (page 15).

— 1 —

Final Report

Letter of conformance by TÜV Süd Rail, 26.09.10:Re: Evaluation of SAMS – control softwareWe would like to confirm to you that SAMS software, the softwarefor computing velocity-dependent safety zone for autonomous mobilerobots, has been developed according to the software development pro-cess as laid out in IEC 61508-3:2008 (SIL 3).The related analyses and tests have shown that there are no safety re-lated objections against the use of SAMS software for the computationof velocity dependent safety zone.

Letter of conformance by TÜV Süd Rail, 06.10.10:Re: SAMS Verification EnvironmentWe would like to confirm that the SAMS Verification Environment andthe theorem prover Isabelle are applicable in use for the specificationand formal verification of MISRA-C software libraries according to thestandard IEC 61508-3:1998 up to SIL 3. In particular, the SAMS verifi-cation environment covers the following measures and procedures fromthe standard IEC 61508-3:1998:Table A.4: 1c, 2, 5, 6Table A.9: 1, 3Table B.1: completelyTable B.8: 1, 3, 4, 5, 8The related analyses and tests have shown that there are no safety-related objections against the use of the SAMS Verification Environmentfor software verification in the phases system design, module design andimplementation.

Figure 1: Letters of conformance for the control software and the verification environment.Copies of the letters can be found in the appendix (pages 11, 13).

— 2 —

Final Report

2.1 Conservative Braking Model

The braking model describes the behaviour of the autonomous vehicle (equipment under control,EUC) during the braking procedure, from first initiation until standstill. The requirements of thebraking model were as follows:

(i) It has to be safe, meaning it has to describe at least the area covered while braking,or in other words, it has to be a conservative approximation.

(ii) It has to apply to as many as possible autonomous vehicles used in industry (inparticular AVGs).

(iii) Configuration has to be simple, ideally with just one measurement, a requirementborne from industrial practice of Leuze electronic as a leading supplier of config-urable safety applications.

The braking model developed in SAMS covers these requirements. It can be used for all vehicleswhich have at least two wheels which are not steerable (i.e. vehicles which can not move side-ways). Examples of suitable vehicles include vehicles with a differential drive, and vehicles withone steerable and one unsteerable axis, where the steering angle is fixed during braking. (Theprecise requirements can be found in the user manual, available at the project website.) Furtherrequirements include

(1) a convex contour of the vehicle;

(2) the braking accelaration must grow in direct proportion (or less) to the velocity;

(3) and that the reduction of kinetic energy during braking is the same for braking bothwhen driving straight or in a curve.

These are all realistc assumptions, e.g. the convex contour can always be achieved by taking theconvex hull of the contour proper.The braking model starts with measuring the braking distance when driving straight. By thesecond assumption above the braking behaviour can be estimated as a convex curve with fewmeasurements. Fig. 2 shows the exact braking behaviour as a red curve, which is approximatedwell enough with even a single measurement (green line), and nearly exactly with two measure-ments (blue lines).From the braking distance when driving straight with velocity vG the braking distance whendriving in curve with velocity v and rotational velocity ω is derived by the third assumptionabove (Fig. 2, right). The model assumes that the kinetic energy is additionally reduced duringbraking in a curve by the centripetal force keeping the vehicle in the curve (the details of thiscan be found in the concept paper, Konzeptpapier Bremsmodell, available at the project website).Thus, no measurements for braking in a curve need to be taken.The braking model has been certified as applicable in a safety function by TÜV Süd, and its prac-tical usability has been demonstrated in experiments; in particular, it does not reduce availabilityby overapproximating the braking area by too much.

— 3 —

Final Report

vG

(v, ω)

Figure 2: Configuring the braking model (left), driving straight and in a curve (right)

2.2 Algorithm to Compute Safety Zones

Mathematically, the braking model describes a function which maps the vehicle from the origin(0,0) to the position where it comes to a standstill when braking with velocity ~v (consisting ofscalar velocity v and a steering angle ω , considered as a vector). By integrating over time weobtain the area covered during the braking procedure. This area has to be expanded by severalmargins required by the relevant norms:

(i) To accomodate for errors in the measurement of odometry (measuring the velocityvector) and to accomodate for velocity-dependent error margins (such as latencytimes and wear and tear of the brakes), the safety zone is not computed for a singlevelocity, but for an interval.

(ii) Furthermore, the safety zone is extended by a fixed, constant amount to all sides inthe end; this models the required velocity-independent safety margins.

After the computation of the safety zone as a polygon it is transferred into a series of distancemeasurements suitable as input to a laser scanner. Fig. 3 illustrates the computation.

(a) (b) (c) (d) (e)

Figure 3: Calculating the safety zone. Movement in a curve until standstill (a) is covered by aconvex polygon (b), velocity-dependent (c) and velocity-independent margins (d) are added, andfinally transferred into laser scanner input (e).

— 4 —

Final Report

If the calculated safety zone is monitored by a safety laser scanner, and if braking is initiatedwithin the specified time limits upon detection of an obstacle in the safety zone, then safety fromcollision with static obstacles can be guaranteed. This property has been formally proven withthe verification environment developed in this project (see Section 2.3). TÜV Süd has reviewedboth the algorithm and our implementation in MISRA-C, and has no objections for use in safety-critical applications up to SIL 3 according to IEC 61508-3.The review comprised all project documents required by IEC 61508-3, including concept papersdescribing the braking model and the calculation of the safety zone, a software FMEA, a soft-ware criticality analysis, requirements specification and safety requirements specification, designspecification, verification and validation plan (v&v plan), test plan, and a user manual. Thoseproject documents which are not confidential are avaliable publicly on the SAMS website athttp://www.dfki.de/sks/sams/papers/documents/.

2.3 Verification Environment

The SAMS verification environment is used to formulate and prove the correctness conditions forthe implementation of the safety zone calculation in MISRA-C. For the verification environment,we had the following requirements:

(1) Specifications should be written in an understandable, formal language close to thecode.

(2) The environment should support formal proof correctness, that is machine-supportedproof using an established theorem prover to check correctness.

(3) The environment should be applicable to software systems according to IEC 61508SIL-3.

Specification follows design by contract, the C functions are annotated with pre- and postcondi-tions. Fig. 4 shows an example specification. In addition to pre- and postconditions, we also haveto specify which parts of the memory are possibly affected by this function. If such a function isproven as correct, the following has been shown:

(i) functional correctness: if the precondition holds when the function is called, thenthe postcondition will hold after the function has terminated;

(ii) termination: if the precondition holds when the function is called, then the functionwill terminate;

(iii) program safety: if the precondition holds when the function is called, all pointerdereferences and array accesses are well defined, and there will be no divisions byzero;

(iv) memory safety: if the precondition holds when the function is called, only thoselocations in memory specified by the modifies clause may have changed.

— 5 —

Final Report

/∗@@requires \ separated ( v , l en , v_res , l e n )

&& $ ! istSKT (m)@ensures 0 <= \ r e s u l t <= l e n &&

${ ^PSet{v_res , \ r e s u l t } =^SKT{m} ‘ ^PSet{v , \ r e s u l t } }

@modifies v_res [ : l e n ]@∗/

i n t t r a n s f o rm i e r e ( Punkt ∗ v , Punkt ∗ v_res ,i n t l en , Mat r i x ∗ m) ;

Figure 4: Specification of a function implementing a rigid body transformation. @requires isthe precondition, @ensures is the postcondition, and @modifies specifies changes in memorymade by this function.

The specification language follows established languages such as JML (for Java) or ACSL (forC), but additionally supports the embedding of Isabelle expressions in specifications. This al-lows to make use of Isabelle’s powerful higher-order constructions and rich libraries and datastructures (sets, lists, integers, reals) in the specifications. This additional expressive power hasturned out to be an invaluable advantage in our application. The exact syntax and semantics canbe found in the reference manual of the verification environment, available at the project website.The verification environment is based on total Hoare calculus, embedded in the theorem proverIsabelle. A syntactic front-end translates program and specification into Isabelle input. Isabellereduces the specifications to proof obligations by syntax-directed rule applications and additionaltactics; the proof obligations can either be shown automatically or interactively (Fig. 5). Thetechnical details were published in a paper [3] on the Formal Methods 09 conference.

Figure 5: Architecture of the verification environment.

— 6 —

Final Report

Crucial for the realisation of the third requirement above is that the correctness proof is based onIsabelle to an overwhelming extent. If the correctness of Isabelle can be assumed (in the sensethat only logically correct theorems can be proven in Isabelle), then correctness of the verifica-tion environment reduces to the correctness of the proof calculus, which in turn reduces to thequestion whether the semantics of the fragment of the C language is modelled adequately accord-ing to the language standard ISO 9899:1990, because the rest of the verification environment isdeveloped conservatively.The verification technique developed here, and in particular the verification environment, havebeen reviewed by TÜV Süd Rail, and can be used for specification and verification of MISRA-Csoftware according to IEC 61508-3 up to SIL 3; this was conformed in a letter which can befound in the appendix (p. 13).

2.4 Three-dimensional Safety Zones

A generalisation of the safety zone calculation allows the calculation of safety zones in threedimensions, and can be used to safeguard machine movements in three dimensions, such asrobot arms or other manipulators, against collisions with each other or with other obstacles.When generalising the calculation of the safety zones from two to three dimensions we have tocalculate volumes rather than areas. The main computational ingredient here is the modelling ofthe volume of the safety zone as the convex hull of a finite set of points with an additional buffer,together with a novel algorithm capable of computing the safety zone using this model in realtime. Fig. 6 shows an application example.

Figure 6: Example for three-dimensional safety zones: DLR robot Justin clapping his hands.The calculated safety zones are shown in green.

— 7 —

Final Report

3 Dissemination

3.1 Safety Zones and Verification Environment

The certified implementation of the safety zone calculation will be made available to the publicvia open source; currently, the software is being prepared to be integrated into an establishedrobotics framework like Player/Stage, which would allow for an easier evaluation and use byinterested parties.The verification environment will also be released publicly, in open source form. It is currentlybeing cleaned up, with added installation procedures and in particular adequate documentation;this work is scheduled to be finished by the second half of 2010, coinciding with submission ofthe main author’s thesis [1].

3.2 Commercial Use

Some of the general concepts developed during the SAMS project have already been integratedinto the ROTOSCAN RS4Motion safety laser scanner produced by Leuze electronics. SAMSwill play a larger rôle in the next generation of safety laser scanners from Leuze, the developmentof which has started in 2009. Of particular relevance will be the simplification of use for the end-user, which is well supported by the configuration mechanism as developed in SAMS.Patent has been applied for the generalisation of the calculation of safety zones in three dimen-sions by DFKI; interested parties are invited to inquire at DFKI for conditions of use.

3.3 Publications and Presentations

The central dissemination platform for the results is the SAMS project website. http://www.sams-projekt.de or http://www.sams-project.org, where results are presented in Ger-man and English, including all project documents, presentations, publications, and the softwareproducts when they will become available.The final presentation of the project took place in Bremen on October 13th 2009, with over fiftyparticipants. The talks can be found on the website as well.

— 8 —

Final Report

A List of publications

[1] Dennis Walter. A Formal Verification Environment for the Use in the Certification of Safety-Related C Programs. Dissertation, Fachbereich 3 der Universität Bremen. Forthcoming.

[2] Dennis Walter, Holger Täubig, Christoph Lüth. Experiences in Applying Verification inRobotics. In SafeComp2010 - 29th International Conference on Computer Safety, Reliabilityand Security. To appear in Lecture Notes in Computer Science, Springer.

[3] Christoph Lüth and Dennis Walter. Certifiable specification and verification of C programs.In Ana Cavalcanti and Dennis Dams, editors, Formal Methods (FM 2009), volume 5850 ofLecture Notes in Computer Science, pages 419–434. Springer, 2009.

[4] Leuze electronic. Sicher auf Distanz. handling, April 2009.

[5] Stefan Mohr. Ein Scanner für alle Fälle. elektro AUTOMATION, März 2009.

[6] Udo Frese and Holger Täubig. Verfahren zur Vermeidung von Kollisionen gesteuert be-weglicher Teile einer Anlage. Research Report RR-09-01, Deutsches Forschungszentrumfür Künstliche Intelligenz, 2009.

[7] Stefan Mohr. Ein Scanner für alle Fälle. GIT Sicherheit + Management, Dezember 2008.

[8] Maksym Bortin, Christoph Lüth, and Dennis Walter. A certifiable formal semantics of C. InTarmo Uustalu, Jüri Vain, and Juhan Ernits, editors, 20th Nordic Workshop on ProgrammingTheory NWPT 2008, Technical Report, pages 19– 21, Tallinn, Estonia, November 2008.Institute of Cybernetics, Tallinn University of Technology.

[9] Stefan Mohr. Die Bewegung im Griff. Computer & Automation, November 2008.

[10] Christoph Lüth, Udo Frese, Holger Täubig, Dennis Walter, and Daniel Hausmann. SAMS:Sicherungskomponente für Autonome Mobile Serviceroboter. In VDI-Bericht, volume 2012.VDI-Verlag, 2008.

[11] Stefan Mohr. Sensorlösung für sichere Fahrt. A&D Industrielle Automation, September2008.

[12] Stefan Mohr. Scanner in Motion. GIT Sicherheit + Management, Mai 2008.

[13] Udo Frese, Daniel Hausmann, Christoph Lüth, Holger Täubig, and Dennis Walter. Theimportance of being formal. In Hardi Hungar, editor, International Workshop on the Cer-tification of Safety-Critical Software Controlled Systems SafeCert’08, Electronic Notes inTheoretical Computer Science. Elsevier Science, 2008.

— 9 —

Final Report

[14] Udo Frese, Daniel Hausmann, Christoph Lüth, Holger Täubig, and Dennis Walter. Zerti-fizierung einer Sicherungskomponente mittels durchgängig formaler Modellierung. In Soft-ware Engineering 2008, volume P-122 of Lecture Notes in Informatics, pages 335– 338.Gesellschaft für Informatik, 2008.

[15] Christoph Lüth and Bernd Krieg-Brückner. Sicherheit in der Künstlichen Intelligenz. Kün-stliche Intelligenz, 1:51– 52, 2007.

— 10 —

Final Report

— 12 —

Final Report

— 14 —