This paper summarizes the objectives and structure of a
seminar with the same title, held from June 10th to June 15th, 2007
at Schloss Dagstuhl, Germany

Huhn, Michaela

Hungar, Hardi

Peled, Doron A.

Dagstuhl Research Online Publication Server

07241  SummaryTools for the Model-based Development of Certiﬁable,Dependable SystemsJune 10th to June 15th 2007 Dagstuhl Seminar Michaela Huhn1, Hardi Hungar2, and Doron Peled31 Technische Universtät Braunschweig, Carl-Friedrich-Gauß-FakultätD-38106 Braunschweig, Mühlenpfordtstr. 23, GermanyM.Huhn@tu-braunschweig.de2 OFFIS, Safety Critical SystemsD-26121 Oldenburg, Escherweg 2, Germanyhungar@offis.de3 University of Warwick, Department of Computer ScienceCoventry, CV4 7AL, United Kingdomdoron@dcs.warwick.ac.ukAbstract. This paper summarizes the objectives and structure of aseminar with the same title, held from June 10th to June 15th, 2007at Schloss Dagstuhl, Germany.Keywords. Dependable systems, safety, security, certiﬁcation, formalmethods, modelling, veriﬁcation, tools.1 IntroductionThe development of software for dependable systems on which the safety orsecurity of individuals, organizations, and property may rely has become an im-portant application and research ﬁeld. In many cases, law enforces certiﬁcationas a prerequisite for the introduction of a technical, dependable system. Thecertiﬁcation formally assures that the systems and its development process meetthe technical standards and all eﬀorts have been made to reduce the risks. Thecomplexity and discrete nature of software makes an assurance of the requiredproperties of the software components of a dependable system extremely dif-ﬁcult. This applies even more as the software often constitutes the control ina so-called embedded system where coupling electronic and mechanical compo-nents is still a challenge. The relevant national and international standards (e.g.IEC 61508 [Int00]) recommend formal methods for the development of systemsthat shall be certiﬁed for the higher safety integrity levels. However, derivingconstructive design guidelines and formally veriﬁable software constraints fromsafety requirements on the system level is still a challenging problem.2 M. Huhn, H. Hungar, D. PeledIn many industries developing high-assurance products, model-based designis already well established and a number of tools used in safety-critical soft-ware design are founded on formal semantics and support in parts automatedcode generation, formal analysis, veriﬁcation or error detection. But certiﬁca-tion requires more than formal semantics of a modelling notation or the formalveriﬁcation of the artefacts of a particular development step. Formal methodsand tools have to be embedded in a seamless design process which covers alldevelopment phases and which includes an eﬃcient construction of a safety casefor the product. Moreover, whereas most (semi-)formal modelling approaches fo-cus on functional issues additional concepts are required for dependable systemslike fault tolerance, timing or security. Even if these concepts are addressed as several UML proﬁles do  they are supported at most rudimentarily by thetools.1.1 Some StatisticsThe workshop aimed at bringing together people actually working on the certiﬁ-cation of dependable systems with researchers who develop and validate (semi-)formal methods and tools for modelling and veriﬁcation. About 30 researchersand practitioners followed the invitation. The program featured about 25 pre-sentations, 14 research presentations from academia, 4 reports on experiencesin the certiﬁcation processes of particular products and 6 about practical issuesfrom industrial participants. In addition, a discussion session on the status quoof formal methods in the certiﬁcation of dependable systems was arranged.1.2 The Railway Level Crossing Case StudyTo focus discussions and to directly compare diﬀerent approaches a case studyon the design of the software control for a simple railway level crossing [HHLZ07]was given to the participants beforehand. Several participants addressed the casestudy in their presentation. So it was shown that some immediate shortcomingsin the requirement speciﬁcation could be detected with simple static analysistechniques applied on an abstract design model. This observation was indepen-dent of formal modelling notations actually used. A more subtle ambiguity wasdetected by those approaches that employed formal veriﬁcation on a behaviouralmodel of the level crossing. Another participant used a generalized version of thecase study to prove scalability of a veriﬁcation approach. Last but not least, thecase study has set up the discussion to what extend implicit assumptions arerevealed when transferring an informal requirements speciﬁcation into a formalmodel and how to deal with diﬀerent categories of implicit assumptions method-ologically.07241 Summary 32 Discussion on the Status Quo of Formal Methods andCertiﬁcation of Dependable SystemsOn each of the issues raised during the discussion, there was a wide spectrumof partly divergent opinions and observations. A summary of each of the mainthemes follows below.2.1 Mathematical RigourOn the one hand, it was reported, that all necessary techniques were availableto treat the subject satisfactorily. By a relevant number of pilot projects it hasbeen proven that systems of impressive size can be veriﬁed working with theoremproving or model checking on the basis of a cleanly and well deﬁned semanticsfor systems and problem statements. A decomposition into well-built layers, eachveriﬁed itself, and dedicated construction of relations between layers, was consid-ered to be a successful approach. This goes very well with the model-based designparadigm, because most model-based development processes provide modellingguidelines for diﬀerent levels of abstraction. The proponents of a rigorous formalapproach were convinced that even the popular counter-arguments - as ongoingproblems with scalability of formal veriﬁcation, the high investments needed todevelop the initial foundation of a formal process (e.g. veriﬁed layers), and thesevere shortage of experts who have profound knowledge on formal methods andthe application domain - would merely be surmountable obstacles.This positive view was not shared by everybody. First of all, a number ofparticipants considered the mentioned obstacles to be substantial. Additionally,the maturity of formal methods and tools was challenged: So far, a relevantportion of the success stories was achieved with prototype tools in a researchenvironment. These are not easily transferred into the ﬁelds of practice, not onlybecause matters like tool support, robustness and scalability, and domain speciﬁcadaptations have to be solved for industrial development. The most importantbarrier for introducing academic tools in dependable system industries is thatcertiﬁcation imposes high requirements not only on the products and the processbut also on each tool used in the development and in particular for qualityassurance.2.2 Veriﬁcation and Validation ToolsThere was a general agreement that tool support for veriﬁcation and validation(V&V)is indispensable and will grow in its importance in the following years.There were of course, again, diﬀering viewpoints.One observation concerned the introduction of new analysis methods likehybrid model checking into the ﬁeld of (control) engineering. Up to now, thesemodel checkers have not yet shown much promise to be able to handle evenmedium size designs. Are, henceforth, the "classical" engineering techniques inthis ﬁeld going to be replaced in the foreseeable future? And how are they, then,going to be integrated with formal speciﬁcations and reasoning?4 M. Huhn, H. Hungar, D. PeledA similar integration concern has been raised with respect to the growingusage of automatic simulation or test generation tools. Though considerableprogress has been made in automation techniques, it is diﬃcult to proﬁt froma tool which does not guarantee complete coverage. Related to this issue is thequestion of how to ﬁnd the "interesting" points via simulation or testing? Hence,these techniques have to be equipped with means to direct the search to thoseparts of the state space where complex and error-prone behaviour occurs, i.e.interactions between components from diﬀerent suppliers, or mode transitions inthe presence of exceptional behaviour. Moreover, the technique should be ableto identify dead code or unreachable parts of the state space or other anomaliesindicating potential errors.To summarize, it shows more promising to speciﬁcally tailor a tool to aparticular purpose explicitly required by regulations than (naively) introducingan unspeciﬁc test generation tool into the V&V process. For example the avionicsstandard DO-178B requires MC/DC coverage, which can be addressed by adedicated procedure relying on abstract interpretation.If requirements are not that strict, as for instance it is often the case inthe automotive domain, it is somewhat easier to proﬁt from the availability ofhigh-level models. This argument gets detailed in the section on processes.2.3 SpeciﬁcationThe question of whether speciﬁcation has to be formal is controversial. Clearly,formality helps to uncover errors and to avoid misinterpretation, and eases subse-quent automation and application of formal techniques. Additionally, the ubiq-uitous UML [Obj05] carries the promise of an emerging de-facto standard ofbecoming a lingua franca, understood across domains.There are obvious objections concerning the communicability of formalismsand the diﬃculty of checking consistency and completeness. These are more se-vere deﬁciencies in a formal than in an informal speciﬁcation, since the latterappeals more to the developer's experience and competence. Also, it was saidthat speciﬁcation is "inherently an iterative process", where some aspects can-not be ﬁxed before at least a prototypical exploration of the design is applied.That speciﬁcation cannot be ﬁxed up front is experienced even in cases wherestandards require this explicitly, like the EN 50128 [CEN01]. Often, customersrequire late changes to a product. To incorporate such changes into a speciﬁca-tion is usually more diﬃcult when the speciﬁcation is formal.Finally, UML is not naturally suited for every kind of application: Parts of theUML are not unambiguously deﬁned, others presume a particular model of exe-cution as for instance statecharts [HK04] with event pools and run-to-completionsemantics, that does not match the semantic world of every application. For mod-elling the hardware architecture appropriately, which is an integral part of mostdesign and analysis tasks in dependable system development, the UML adoptionSysML [Obj07] plus proﬁles like MARTE [Obj06] are needed.There was wide agreement that there is no one language for formal speci-ﬁcation, nor could there be one. Application-speciﬁc languages certainly have07241 Summary 5their place, as well as weak formalisms like the UML for communication pur-poses. Whether one should strive for full formality depends at least today on themeans available and on the requirements.2.4 ProcessThe speciﬁcation is only one of the artefacts to be produced in a design process.The seminar's focus was on dependability and safety, so their role was promi-nently discussed. In several domains standards prescribe a process skeleton; anda number of well established industrial processes for developing dependable andcertiﬁable systems instantiate and reﬁne these skeletons.Typically, certiﬁcation and thus development processes for dependable sys-tems necessitates construction of an argument of safety in a formalised document a so-called safety case. It is considered advisable to take speciﬁc care so thatthe safety case construction can be done hand-in-hand with the development,i.e. integrate safety arguments with speciﬁcation reﬁnement and implementa-tion. Today, this is not yet done satisfactorily eﬃcient. Improvements will mostlikely be possible on a basis of formal development artefacts. Some safety con-cerns give rise to additional functional requirements, e.g., when redundancy orwatchdog constructs are introduced as safety measures. Here, a tight integra-tion of the design steps and the construction of the safety case is particularlyrecommended.Another issue is the structure in the line of arguments in the safety case itself.Approaches like Goal Structuring Notation [Kel98] improve the conciseness andunderstandability of reasoning. Moreover, context information and constraints,limiting the applicability of a particular argument or reasoning method, can bemade explicit. However, full integration with model-based design methods orformal V&V methods is missing so far.In the automotive area, a domain-speciﬁc standard for the development ofsafety related electronic programmable systems is still pending (e.g. ISO WD26262). Here, the development of automotive systems is performed accordingto an iterative, approximative process. First a core control model is developedon the basis of an ideal plant model. In the next step the normal behaviour ofthe control model is explored and validated in the real plant. Then exceptionalbehaviour and speciﬁc case treatment is added to the control model. Then a ﬁne-tuning and optimization phase follows. Finally, the control model is transformedinto target speciﬁc code, which is validated against the runs of the ideal model.In all phases, design proceeds based on the division of labour between OEM andsuppliers.3 ConclusionIt was commonly agreed that formal speciﬁcation has already reached the stageof being an eﬀective support in the development of software-intensive dependablesystems and that its role will increase in the future.6 M. Huhn, H. Hungar, D. PeledTechnical progress in veriﬁcation, for instance in component-oriented rea-soning (assume-guarantee proofs) and (semi-)automated abstraction techniques,signiﬁcantly expand the potential for applying formal methods on complex sys-tems.A tighter integration of models for design and models for veriﬁcation has al-ready begun and proven to be a key factor for the introduction of formal methodsinto the industrial practice. A number of veriﬁcation approaches directly startwith design models from UML or Matlab/Simulink as analysis input and oﬀerseamless tool integration. However, these methods are often restricted to oneparticular veriﬁcation goal that is considered relevant in one design phase or toa single concern like functional correctness or timing. Thus, a major challengefor the future will be to integrate formal approaches dealing with the diﬀerentconcerns that contribute to safety like functional correctness, reliability, timing,et cetera.ReferencesCEN01. CENELEC. EN 50128: Railway applications - Communications, Signallingand Processing Systems - Software for Railway Control and Protection Sys-tems. European Standard., March 2001.HHLZ07. Hardi Hungar, Michaela Huhn, Oliver Lemke, and Axel Zechner. Tools forthe model-based development of certiﬁable, dependable systems: Case studyrailway level crossing, June 2007.HK04. David Harel and Hillel Kugler. The Rhapsody semantics of statecharts (or,on the executable core of the UML). In H. Ehrig et al., editor, Integration ofSoftware Speciﬁcation Techniques for Applications in Engineering, number3147 in LNCS, pages 325  354, 2004.Int00. International Electrotechnical Commission. IEC 61508 Functional Safetyof Electrical/Electronic/Programmable Electronic Safety-related Systems Part 7: Overview of Techniques and Measures, March 2000.Kel98. Timothy Kelly. Arguing Safety  A Systemic Approach to Managing SafetyCases. PhD thesis, University of York, September 1998.Obj05. Object Management Group. Uniﬁed Modeling Language: Superstructure,August 2005.Obj06. Object Management Group. UML Proﬁle for Modeling and Analysis ofReal-Time and Embedded Systems (MARTE) rfp, 2006.Obj07. Object Management Group. SysML speciﬁcation v. 1.0, August 2007.

07241 Summary --  Tools for the Model-based Development of Certifiable, Dependable Systems

http://drops.dagstuhl.de/opus/volltexte/2008/1405/pdf/summary_proceedings.1405.pdf

07241 Summary -- Tools for the Model-based Development of Certifiable, Dependable Systems

Abstract

Similar works

Full text

Available Versions

Dagstuhl Research Online Publication Server