Towards a Formalism-Based Toolkit for Automotive Applications

Towards a Formalism-Based
Toolkit for Automotive Applications

Rainer Gmehlich, Katrin Grau, Felix Loesch
Robert Bosch GmbH, Stuttgart, Germany
   Alexei Iliasov, Michael Jackson, Manuel Mazzara
School of Computing Science, Newcastle University, UK
Abstract

The success of a number of projects has been shown to be significantly improved by the use of a formalism . However, there remains an open issue: to what extent can a development process based on a singular formal notation and method succeed. The majority of approaches demonstrate a low level of flexibility by attempting to use a single notation to express all of the different aspects encountered in software development. Often, these approaches leave a number of scalability issues open. We prefer a more eclectic approach. In our experience, the use of a formalism-based toolkit with adequate notations for each development phase is a viable solution. Following this principle, any specific notation is used only where and when it is really suitable and not necessarily over the entire software lifecycle. The approach explored in this article is perhaps slowly emerging in practice —we hope to accelerate its adoption. However, the major challenge is still finding the best way to instantiate it for each specific application scenario. In this work, we describe a development process and method for automotive applications which consists of five phases. The process recognizes the need for having adequate (and tailored) notations (Problem Frames, Requirements State Machine Language, and Event-B) for each development phase as well as direct traceability between the documents produced during each phase. This allows for a step-wise verification/validation of the system under development. The ideas for the formal development method have evolved over two significant case studies carried out in the DEPLOY project.

automotive, formal modelling, requirements, Event-B, Problem Frames, RSML

I Introduction

One of the lessons of the DEPLOY project [1] is that the industrial application of formal modelling cannot fully succeed by employing just one notation, paradigm and methodology. The focus of academic research in DEPLOY was a method called Event-B[2] - a general-purpose, event-based and refinement driven formal modelling method - and a toolkit supporting it - the Rodin Platform [3]. A wide range of case studies and formal developments were conducted during the predecessor RODIN project [4] and this provided a reasonable expectation that the method and the Platform could succeed in large-scale industrial deployments. This paper describes the experience of deploying Event-B in an automotive sector. In particular, we tell the story of how a sole notation approach based on Event-B has gradually transformed itself into a rich assembly of diverse notations and techniques.

Formal/mathematical notations have existed for a long time and have been used to specify and verify systems. Examples are process algebras (a short history by Jos Baeten in [BaetenPA]), specification languages like Z (early description in [5]), B [6] and Event-B [7]. The Vienna Development Method (VDM) is one of the earliest attempts to establish a formal method for the development of computer systems [8, 9, 10]. A survey of these (and others) formalisms can be found in [11] while a discussion on the methodological issues of a number of formal methods is presented in [12, 13, 14].

All these approaches (and others described in the literature) still leave an open issue, i.e., they are built around strict formal notations which affect the development process from the very beginning. These approaches demonstrate a low level of flexibility. It is indeed not reasonable to expect that a single notation can express all the different aspects encountered during the software development cycle. Therefore, these methods seem to work only for small problems, leaving a number of scalability issues open.

In this paper, following the experience accumulated during the FP7 DEPLOY project [1], we offer to consider a position where a development toolkit and its supporting method are based on a range of notations or formalisms that complement each other. Each such notation may target a specific stage of a development - early requirements elicitation, concrete requirements, abstract design, concrete design, first prototype, final product and so on - with some degree of overlap to give a degree of confidence when progressing through notations.

One challenge is in making a seamless methodological connection between diverse notations and methods: how to ensure that results expressed in one notation are carried over to the next stage based on a differing notation without misinterpretation of specification statements and mis-attribution of validation results.

Another challenge is in the provision of a modelling environment that can adopt all such notation and possibly integrate validation tools behind them. Finally, and perhaps most importantly, it is important to have some degree of notational flexibility - industrial software development is already based on long tool chains and the most likely path to succeed for a formal development method to succeed is to morph into such chain. That is, be prepared to work with new input and output notations.

Ii Background

This section gives a short introduction to the different methods on which the approach proposed is based. It is not intended to be exhaustive, but it provides the reader with relevant pointers for further investigation.

Ii-a Problem Frames

PFA [15] focuses on systems in which the computer interacts with the physical world to achieve a required behaviour there. Stakeholders in the system –users, sponsors, operators, regulators and others– want this behaviour to satisfy certain properties. These desired properties may be expressed in various forms and with various degrees of exactness: for an industrial press a vital desire is the operator’s safety; for an electronic purse system it is conservation of money in any transaction between two purses even if the transaction fails or is aborted. The requirements engineer must understand these desires and design a feasible joint behaviour of the computer and the world that will satisfy them.

In PFA this task is understood in terms of three principal parts. First, the machine: this is the computer executing the software that will eventually be developed. Second, the problem world, seen as an assemblage of distinct domains interacting with each other and with the computer. Third, the system requirement, initially seen as the set of desired properties of the system behaviour. The system is represented in a problem diagram. The diagram shows the computer, the problem domains, and the interfaces of shared phenomea at which they interact; the requirement is represented by a distinguished block linked to the problem domains to whose phenomena it refers. The requirements engineering task is to specify the given properties of the problem world domains, the behaviour of the computer, and the required joint behaviour resulting from their interactions. The entailment must hold, and the behaviour must exhibit the properties desired by the stakeholders.

For a realistic system and the desired properties will be complex. The problem is therefore decomposed into subproblems, each represented by a problem diagram. A subproblem is a closed independent projection of the original problem, ignoring all interactions with other subproblems. Recombination is deferred until each subproblem is well enough understood in isolation. A further task is then to design the temporal composition of the subproblem behaviours and to resolve any interference and conflict arising in their resulting interactions.

This specification of system behaviour does not map directly either to an Event-B specification or to a software architecture: refactoring is a further step in the path to implementation. It is a fundamental claim of PFA that the cost of this refactoring is amply compensated by the clarity that can be achieved in the requirements engineering task itself and the consequent improvement in system quality and dependability.

Ii-B Requirements State Machine Language (RSML)

X Y
A B
S = PRESSED
Y = ON
TABLE I: Example of an AND/OR table

The Requirements State Machine Language (RSML) [16] is a formal black-box specification language invented by Nancy Leveson and has been widely applied in the avionic industry for the specification of complex state-based embedded systems like the transition collision avoidance system (TCAS II). RSML was developed in order to have precise description of the functional behaviour of state-based systems which is formal enough to reason about general aspects like completeness and consistency of state machines [17] but still easy enough to be understandable by engineers. The language itself consists of concepts for structuring a large specification, i.e., the language supports modules with defined interfaces as well as formal concepts for describing state machines based on statecharts [18] extending state diagrams with state hierarchies and broadcast communications.

An important concept introduced by RSML is the concept of AND/OR tables which are used to describe conditions for state transitions and conditions for the assignment of variables. Table I shows an example for an AND/OR table. The far-left column of the AND/OR table lists the logical phrases. Each of the other columns is a conjunction (logical AND) of those phases and contains the logical values of the expressions. If one of the columns is true, then the table evaluates to true. A column evaluates to true if all of its elements match the truth values of the associated predicates. A dot denotes ”don’t care”.

Ii-C Event-B

The Event-B Modelling Language [7] was developed by J.-R. Abrial and his team at ETHZ as a specialization of the B-Method [6] and it is used to describe formally systems and reason mathematically about their properties.

An Event-B development starts with the creation of a relatively abstract specification. A cornerstone of the Event-B method is the stepwise development that facilitates a gradual design of a system implementation through a number of correctness-preserving refinement steps. The general form of an Event-B model (or machine) is shown in Figure 1. Such a model encapsulates a local state (program variables) and provides operations on the state. The actions (called events) are characterised by a list of local variables (parameters) , a state predicate called event guard, and a next-state relation called substitution or event action.

Fig. 1: Event-B machine structure.

Event guard defines the condition when an event is enabled. Relation is given as a generalised substitution statement [19] and is either deterministic () or non-deterministic update of model variables. The latter kind comes in two notations: selection of a value from a set, written as ; and a relational constraint on the next state , e.g., .

The INVARIANT clause contains the properties of the system, expressed as state predicates, that must be preserved during system execution. These define the safe states of a system. In order for a model to be consistent, invariant preservation is formally demonstrated. Data types, constants and relevant axioms are defined in a separate component called context.

Model correctness is demonstrated by generating and discharging proof obligations - theorems in the first order logic. There are proof obligations for model consistency and for the refinement link - the forward simulation relation - between the pair of abstract and concrete models. One can say that an abstract model serves as a contract when realising the concrete model.

Iii Our Approach

Our approach to formal development process for automotive applications 111Automotive applications contain discrete and continuous parts (closed loop controllers). In the case studies we concentrated on the discrete part of the system. We decided not to model the continuous part and only used an abstract notion of time. evolved after having experimented over two significant case studies in the DEPLOY project [1]. During these case studies we found that the semantic gap between informal descriptions (i.e., requirements in natural language and formal descriptions of the system in Event-B) is significant. Checking that the formal descriptions are consistent with the informal descriptions turned out to be a difficult task because of the inevitable vagueness of informal descriptions and missing traceability links between the informal and formal descriptions.

In order to bridge this gap and to progress incrementally from an informal to a formal description of the system, our approach consists of five phases (requirements, specification, formal modelling, formal verification, and code generation) in each of which a carefully selected notation and methods are used. A specific formalism is used only where and when it is really suitable and not over the complete development cycle.

The outcome of each phase during the development process is an adequate document which describes the results of each phase and which can be used to communicate with other stakeholders like managers, customers, and other developers during the development process. To ensure traceability between the documents produced in different phases we establishment and maintain links between requirements and modelling artefacts implementing them. Hence, for instance, an RSML and Event-B models may be related by comparing model elements related to same requirements. Since each notation is tailored to its phase it becomes much easier to do informal model validation - ensuring that the model adequately addresses informal requirements. This process is crucial at the stage when concrete requirements are elaborated.

Figure 2 graphically depicts our development process.

Fig. 2: Formal development process

The starting point for our process is an abstract idea of the system and/or some vague initial requirements (see step 1 in Figure 2). In order to produce a requirements document for further development these vague initial requirements have to be analyzed and concrete requirements have to be developed. For this analysis and development PFA [15] is applied. The main outcome of this phase is a requirements document in natural language which also contains assumptions on the system to be developed. We deliberately chose to describe requirements in natural language in order to make it as easy as possible to discuss the requirements with different stakeholders in the development process (e.g., customers and managers). Section IV-A describes this phase.

The next phase in the process is the specification phase in which the desired functional behaviour of the system and the architecture is described in a precise way using RSML [16] (see step 2 in Figure 2). Inputs to this phase are the requirements document as well as the Problem Frames model. The outcome of the specification phase is a specification document which contains a description of the architecture of the solution as well as a detailed description of the functional behaviour of each component. A detailed description of this phase is presented in Section IV-B.

After the specification phase the formal modelling phase follows (see step 3 in Figure 2). During this phase the specification is translated into a formal model written in a formal language (e.g., Event-B). The main activities in this phase are the formalization of the functional behaviour, i.e., how the system is achieving it, as well as the formalization of requirements, i.e., what the system should do. Section IV-C contains a detailed description of the formal modelling phase.

The next phase in our approach is the formal verification phase (see step 4 in Figure 2). In this phase the refinements of the formal model as well as the formalized requirements are verified on the model using formal verification techniques such as theorem proving and model checking. The outcome of the verification phase is a verified formal model with regard to the formalized requirements.

Iv Formal Development Method

This section presents a detailed description of the five phases of our approach. For each phase of our approach the specific requirements and constraints for choosing an adequate (formal) notation are discussed before we present the arguments for how the chosen notation fulfils the requirements of each phase. The description of each phase is illustrated using an example from our second case study in the DEPLOY project [1].

The system we analyzed in our second case study was a Start/Stop System which automatically stops the engine, e.g., at traffic lights, to save fuel (see also [20]). The engine will be automatically restarted when the driver wants to move the car again. The system is an embedded real time system. However, contrary to other software functions in the automotive domain, the Start/Stop System only consists of discrete functionality containing a complicated state machine for determining when to stop and when to start the engine.

Iv-a Requirements Development

Constraints The starting point for a new product or a new feature for a product is usually an abstract idea, some vague initial requirements. To produce a requirements document which can be used for further development these initial requirements have to be refined. We used Problem Frames [15] for the problem analysis and the central idea of this first part of the development process is to concentrate on the problem that has to be solved, not on possible solutions. During this analysis, having some structure helps to find a systematic way to analyse the problem. On the other hand, a completely formal notation would restrict the freedom needed during this early phase.

Description of method In PFA we start with an abstract diagram, an overview of the world of which the system to be built is a part. An abstract requirement describes the effect the system has on the world. Note that the requirement does not refer to the system itself (which would be a restriction of the solution). After this abstract examination more concrete sub-problems are considered. In these sub-problems one aspect of the overall problem is developed in detail with requirements that refer only to this specific aspect. The problem of how to recombine these different aspects is postponed and addressed after the development of all sub-problems. In every sub-problem there is at least one requirement. This requirement refers only to the sub-problem. After the development of every sub-problem in isolation the recombination must address the prioritization of the single sub-problems.

Example: The Start/Stop System is not allowed to prevent the driver from moving the car whenever he or she wishes to do so. This aspect of the Start/Stop System is treated in the Problem Frames sub-problem shown in Figure 3. The machine, i.e., the box with the double vertical stripe, is called , referring to the fact that this subproblem concentrates of the needs of the driver, which are deduced by the HMI (Human-Machine Interface). To be able to solve the recombination problem the engine is not part of the subproblem. Instead a designed domain called is used and therefore the requirement does not refer to the engine (as in the requirements document) but to this designed domain, i.e., the box with the single vertical stripe. The designed domain has a phenomenon named (there is another phenomenon called , which is not relevant for this example but will be used in Example 4). The phenomenon stores the information of this subproblem related to the stopping of the engine, i.e., of whether this sub-problem enables the Start/Stop System to stop the car or not. For more details please see [20]. In the domain a model of the driver is defined, which states the connection mentioned in example 1 in 1.) and 2.) between the wishes of the driver and the steering wheel, the clutch and the gearbox. The steering wheel can be used or not used, the clutch pedal can be pressed or released, the gearbox can be in neutral or not in neutral.

Fig. 3: Problem Frames sub-problem

Summary The use of Problem Frames helps to concentrate on the problem to solve and develop a better understanding of how the system to build is supposed to affect the surrounding world. The additional requirements document in natural language is the basis for discussions with all stakeholders.

Iv-B Specification

Constraints After having produced a requirements document containing the requirements and assumptions on the system, the next step is to develop a detailed specification which should include a precise description of the functional behaviour of the system as well as a formalisation of the overall architecture.

A specification method must be understandable by engineers who are not familiar with formal notations like Event-B. RSML [16] is ideally suited for our task of specifying the functional behaviour of state-based automotive systems because it is easy enough to be understandable for engineers but still formal enough to reason about general aspects of state-based systems and fulfils the other constraints described above. The outcome of the specification phase is a specification document written in RSML which is then used as input for the formal modelling phase.

Description of method For the specification of the system we start with the requirements document and the Problem Frames model produced during the requirements development phase. These documents contain requirements and assumptions about the system to be developed but do not contain a precise description of the desired functional behaviour of the system. Thus, the task for the specification phase is to specify the desired functional behaviour such that it fulfils the set of requirements described in the requirements document. In order to structure the solution, the first step during specification is to think about the general architecture of the system. As with the decomposition of the problem in the requirements development phase, the solution is decomposed into components that describe specific aspects. For each component its interface is precisely defined using typed input and output variables. Components communicate with other components via shared variables, e.g., the output variables of component serve as input variables to component and vice versa. If necessary, a component may also contain internal variables to store values derived from input variables.

Figure 4 shows an exemplary static structure of an embedded controller consisting of two components and and their interfaces.

Fig. 4: RSML - Static structure with components and interfaces

The desired functional behaviour of a component is specified using two concepts. The first concept –called assignment specification– is to relate output variables directly with conditions on input variables using AND/OR tables. The following example taken from the Start/Stop System case study illustrates this concept.

Example 3: The value of the boolean output variable is dependent on specific conditions on the input variables and . These conditions are specified by the assignment specification shown in Figure 5.

Assignment: HMI_Stop_Ena

Condition:

Clutch_Pedal = PRESSED Steering_Wheel = USED Gearbox NEUTRAL

Action(s): HMI_Stop_Ena FALSE

Condition:

Action(s):
HMI_Stop_Ena TRUE

Fig. 5: RSML - Assignment specification for HMI_Stop_Ena

The second concept is to define a state machine whose transitions are guarded with conditions on the input variables. The state machine serves as an abstraction on complicated conditions on input variables and is described using graphical state diagrams showing the states and transitions but not the conditions on the transitions. AND/OR tables are used again to specify the transition conditions.

Summary Applying RSML for the specification of automotive applications showed very promising results. We were able to express the complete functional behaviour of the Start/Stop System in RSML. The language was formal enough to describe precisely the functional behaviour yet still readable by engineers which was very important in order to permit domain engineers to validate the specification against the requirements document without needing special training in formal methods. However, we did not have tool support for RSML which was both an advantage and a disadvantage. The advantage of not having a tool was that it allowed us to have more freedom in the structure of the specification. The disadvantage was that we did not have the possibility of automatically checking the specification for consistency.

Iv-C Formal Modelling

Constraints There are two purposes of the formal modelling phase: One is to translate the specification into a formal model, i.e., a mathematically precise description of the functional behaviour of the system. The second purpose is to formalize the requirements in order to make them amenable for formal verification.
Such a formal model should provide the basis for formal verification. Thus, the formal language used for formal modelling must be formal enough to describe precisely the functional behaviour specified in the specification and to formalize the requirements we would like to prove on the formal model. In order to make these informal descriptions accessible to formal verification they have to be stated formally as well. Furthermore, the formal language must suit the application area (i.e., description of state-based systems) and provide means for structuring the formal model. In addition to that, the formal language must be concrete enough to generate code from the formal model.
Event-B [7] fulfills most of the constraints mentioned above. It is suited for the description of state-based systems since it is based on action transition systems and it is formal enough to describe precisely the functional behaviour as well as a large number of the properties we would like to prove about the system as invariants. Furthermore, it provides a refinement mechanism which allows us to start with an abstract formal model which can later be refined to a concrete model which provides the basis for code generation.

Description of method Formal modelling in the language Event-B typically starts with a very abstract model which is refined step-by-step until the system and the environment has been completely modelled. For the Start/Stop System the formal modelling starts with a very abstract model containing only the output of the Start/Stop System. This model is then refined step-by-step. In each refinement step additional components described in the specification document are added to the formal model. Typed input and output variables of components described in the specification are modelled as variables in the Event-B model. The types of these variables are specified using type invariants. Each assignment specification and each transition of a state machine described in the specification is modelled by events in Event-B, i.e., the conditions for the assignment are described as guards of the event whereas the assignment itself is described using an action of the event. It is important to note that the Event-B model also contains events for the system environment which models changes of system inputs. For example, the Event-B model for the Start/Stop System contains unguarded events modelling changes of input variables such as Clutch_Pedal, Gearbox, and Steering_Wheel.

Example: Figure 6 shows how the assignment specification for the output variable HMI_Stop_Ena in RSML (shown in Example 4) is translated into Event-B syntax.

Fig. 6: Event-B model for HMI_Stop_Ena

As you can see in Figure 6 the output and input variables are modelled as Event-B variables. Their types are specified by Event-B invariants. The assignment specification for the output variable is modelled as two Event-B events depending whether is set to TRUE or FALSE.

The main feature of Event-B with which to state properties for a model is the concept of invariants. These invariants describe predicates that are proven to always hold. Certain safety properties can be easily described as invariants (e.g., if a defined output of the system is generally forbidden). An example from the Start/Stop System is that there should never be the request to start and the request to stop the engine at the same time. This kind of property is naturally suitable for formalization as invariants.

Summary With Event-B and Rodin we were able to model the discrete part of our systems. Rodin has the great advantage of integrating the formal modelling phase and the formal verification phase so they can be treated in parallel — this is important in helping to eliminate errors as soon as possible. Processes like configuration management, variant management, team development, version management etc. have to be better supported. Scalability for industrial applications and more flexibility for decomposition and architecture have to be addressed in the future. For the formalization of requirements the concept of invariants in Event-B shows limitations.

We had over 4000 generated proof obligations in the Start/Stop System, around 90% of proof obligations were proven automatically by the provers integrated in Rodin. A large majority of the remaining manual proofs were very simple and might be proven automatically in the future with better adjustment and further development of the provers.

V Related Work

Costs and benefits of model-based development of embedded systems in the automotive industry have been examined in [21]. The book chapter describes the results of a global study by Altran Technologies, the chair of software and systems engineering and the chair of Information Management of the Technical University of Munich. This work intends to cover a gap in research analyzing the status quo of model-based development and its effects on the economics. One of the authors of this work, Manfred Broy, has a vast literature on software engineering methods applied to the automotive sector, for example [22]. In [23] he presents a perspective which is very close to the one supported by our work. In his paper, Broy, discusses the need for a portfolio of models and methods and he emphasizes the importance of tool support.

Vi Conclusions

Formal methods are considered attractive by many researchers because concepts such as theorems, proof obligations, equations and others can be applied. However, academic attractiveness by itself does not justify industrial deployment. The work presented in this article shows how elaborating a methodology based on a portfolio of different formalism, each tuned to a specific phase of development, allowed for a better set of requirements and, eventually, better code. Another criticism to FM is often based on the idea that specifications fulfilling the requirement of being interpreted formally are hard to write when compared with learning a new programming language. DEPLOY, and in particular the work presented here, actually demonstrated the opposite. On the other hand, the criticism that it is not possible to prove that formal methods can offer the same quality for less is still open, i.e., we have not empirically (numerically) shown that formal methods are cheaper. There is high confidence that the quality is better, but the added value is limited when the quality is already very good.

This article discussed several software engineering issues, some of which are still open at present. The lack of a rigorous and repeatable approach of many ”formal methods” significantly restricts the choice when it comes to identify a suitable formalism for a specific problem. In [12] this issue is historically investigated and the requirements of a ”formal method” are identified to discover that many so-called “methods” are actually no more than notations, i.e., just formalisms without an attached rigorously defined and repeatable, systematic approach. Event-B is not one of those. Its refinement strategy has been demonstrated to be useful when applied to several case studies in a number of projects like RODIN [24] and DEPLOY itself [1]. However, not even Event-B is a panacea applicable to every phase of software development. In this article, we presented a strategy based on a formalism-based toolkit, i.e., a portfolio of formalisms where every specific phase of development has been attacked by a different and suitable notation. The overall strategy proved to be a successful one and, given the thorough documentation generated by the project ([25], [26], [20]), it promises to be repeatable by engineers with an initially limited knowledge of formal methods. The importance of training here cannot be underestimated.

The idea of this paper can be generalized in a way which sees software development as a sequence of stages with associated notations and techniques. Each phase should have an artifact or document as an input and will generate an adequate output. Given this broader framework, what presented in this paper should be considered just a specific instance for an application scenario (automotive). It is a matter of investigation (for which we do not have a full understanding at the moment) how the single (or multiple) notation(s) for each step should be chosen. We also need to understand what criteria inputs and outputs should individually follow and how they should be related to each other (for example in terms of pre and post conditions?). Even if our investigation necessarily leaves all this unsolved, we still believe it has clarified several aspects of industrial deployment of formal methods in automotive applications.

Acknowledgment

This work has been funded by the EU FP7 DEPLOY Project (Industrial deployment of system engineering methods providing high dependability and productivity). We would like to thank Cliff Jones, Alexander Romanovsky and John Fitzgerald for their valuable support.

References

  • [1] “DEPLOY: Industrial deployment of system engineering methods providing high dependability and productivity.” [Online]. Available: http://www.deploy-project.eu/
  • [2] J.-R. Abrial, Modelling in Event-B.   Cambridge University Press, 2010.
  • [3] The RODIN platform, online at http://rodin-b-sharp.sourceforge.net/.
  • [4] “Event-B and the Rodin Platform.” [Online]. Available: http://www.event-b.org/
  • [5] J.-R. Abrial, S. A. Schuman, and B. Meyer, A Specification Language.   New York, NY, USA: Cambridge University Press, 1980.
  • [6] J.-R. Abrial, The B-Book: Assigning programs to meanings.   New York, NY, USA: Cambridge University Press, 1996.
  • [7] ——, The Event-B Book.   Cambridge, UK: Cambridge University Press, 2010.
  • [8] D. Bjørner and C. B. Jones, Eds., The Vienna Development Method: The Meta-Language, ser. Lecture Notes in Computer Science.   Springer-Verlag, 1978, vol. 61. [Online]. Available: https://www.springerlink.com/content/ql766633l472/
  • [9] C. B. Jones, Software Development: A Rigorous Approach.   Englewood Cliffs, N.J., USA: Prentice Hall International, 1980. [Online]. Available: http://portal.acm.org/citation.cfm?id=539771
  • [10] ——, Systematic Software Development using VDM, 2nd ed.   Prentice Hall International, 1990. [Online]. Available: http://homepages.cs.ncl.ac.uk/cliff.jones/ftp-stuff/Jones1990.pdf
  • [11] M. Mazzara and A. Bhattacharyya, “On modelling and analysis of dynamic reconfiguration of dependable real-time systems,” in DEPEND, International Conference on Dependability, 2010.
  • [12] M. Mazzara, “Deriving specifications of dependable systems: toward a method,” in Proceedings of the 12th European Workshop on Dependable Computing (EWDC), 2009.
  • [13] ——, “On methods for the formal specification of fault tolerant systems,” in DEPEND, International Conference on Dependability, 2011.
  • [14] J. Woodcock, P. G. Larsen, J. Bicarregui, and J. Fitzgerald, “Formal Methods: Practice and Experience,” ACM Computing Surveys, vol. 41, no. 4, Oct 2009.
  • [15] M. Jackson, Problem Frames: Analyzing and structuring software development problems.   Addison-Wesley, 2000.
  • [16] N. G. Leveson, M. P. E. Heimdahl, H. Hildreth, and J. D. Reese, “Requirements Specification for Process-Control Systems,” IEEE Trans. Softw. Eng., vol. 20, pp. 684–707, September 1994. [Online]. Available: http://portal.acm.org/citation.cfm?id=188229.188234
  • [17] M. Heimdahl and N. Leveson, “Completeness and consistency in hierarchical state-based requirements,” Software Engineering, IEEE Transactions on, vol. 22, no. 6, pp. 363 –377, jun 1996.
  • [18] D. Harel, “Statecharts: A visual formalism for complex systems,” Sci. Comput. Program., vol. 8, pp. 231–274, June 1987. [Online]. Available: http://dl.acm.org/citation.cfm?id=34884.34886
  • [19] J.-R. Abrial, The B-Book.   Cambridge University Press, 1996.
  • [20] K. Grau, R. Gmehlich, F. Loesch, J.-C. Deprez, R. D. Landtsheer, and C. Ponsard, “DEPLOY Deliverable D38: Report on Enhanced Deployment in the Automotive Sector,” DEPLOY Project, Tech. Rep. D38, 2011.
  • [21] M. Broy, S. Kirstan, H. Krcmar, B. Schaetz, and J. Zimmermann, “What is the benefit of a model-based design of embedded software systems in the car industry?” in Emerging Technologies for the Evolution and Maintenance of Software Models.   IGI Global, 2011, pp. 410–443.
  • [22] M. Broy, “Challenges in automotive software engineering.” in ICSE’06, 2006, pp. 33–42.
  • [23] ——, “Seamless method- and model-based software and systems engineering,” in The Future of Software Engineering.   Springer, 2010, pp. 33–47.
  • [24] “RODIN: Rigorous Open Development Environment for Complex Systems.” [Online]. Available: http://rodin.cs.ncl.ac.uk/
  • [25] C. Jones, “DEPLOY Deliverable D15: Advances in Methodological WPs,” http://www.deploy-project.eu/pdf/D15final.pdf, Tech. Rep. D15, 2009.
  • [26] F. Loesch, R. Gmehlich, K. Grau, M. Mazzara, and C. Jones, “DEPLOY Deliverable D19: Pilot Deployment in the Automotive Sector,” DEPLOY Project, Tech. Rep. D19, 2010.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
116948
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description