A Holistic Approach in Embedded System Development

We present pState, a tool for developing "complex" embedded systems by integrating validation into the design process. The goal is to reduce validation time. To this end, qualitative and quantitative properties are specified in system models expressed as pCharts, an extended version of hierarchical state machines. These properties are specified in an intuitive way such that they can be written by engineers who are domain experts, without needing to be familiar with temporal logic. From the system model, executable code that preserves the verified properties is generated. The design is documented on the model and the documentation is passed as comments into the generated code. On the series of examples we illustrate how models and properties are specified using pState.Comment: In Proceedings F-IDE 2015, arXiv:1508.0338

Constraint Diagrams: Visualizing Assertions in OO Modelling

Describes a notation, constraint diagrams, which allows pre/post conditions and invariants to be expressed visually, rather than in the notation of mathematical logic. The notation is explored through a small case study (a library system). Some conclusions are drawn about the use of the notation in modelling, and its possible impact on tools and semantics. This report has been split into two and considerable revised and updated: Kent (1997b), Kent (1997c)

Variations of model checking

The logic ATCTL is a convenient logic to specify properties with actions and real-time. It is intended as a property language for Lightweight UML models [12], which consist mainly of simplified class diagrams and statecharts. ATCTL combines two known extensions of CTL, namely ACTL and TCTL. The reason to extend CTL with both actions and real time is that in LUML state¿transition diagrams, we specify states, actions and real time, and our properties refer to all of these elements. The analyst therefore needs a property language that contains constructs for all these elements. ATCTL can be reduced to ACTL as well as to TCTL, and therefore also to CTL. This gives us a choice of tools for model checking; we have used is Kronos [13], a TCTL model checker

Dependability checking with StoCharts: Is train radio reliable enough for trains?

Performance, dependability and quality of service (QoS) are prime aspects of the UML modelling domain. To capture these aspects effectively in the design phase, we have recently proposed STOCHARTS, a conservative extension of UML statechart diagrams. In this paper, we apply the STOCHART formalism to a safety critical design problem. We model a part of the European Train Control System specification, focusing on the risks of wireless communication failures in future high-speed cross-European trains. Stochastic model checking with the model checker PROVER enables us to derive constraints under which the central quality requirements are satisfied by the STOCHART model. The paper illustrates the flexibility and maturity of STOCHARTS to model real problems in safety critical system design

Capturing Assumptions while Designing a Verification Model for Embedded Systems

A formal proof of a system correctness typically holds under a number of assumptions. Leaving them implicit raises the chance of using the system in a context that violates some assumptions, which in return may invalidate the correctness proof. The goal of this paper is to show how combining informal and formal techniques in the process of modelling and formal verification helps capturing these assumptions. As we focus on embedded systems, the assumptions are about the control software, the system on which the software is running and the system’s environment. We present them as a list written in natural language that supplements the formally verified embedded system model. These two together are a better argument for system correctness than each of these given separately

Evolvable Integration of Activities with Statecharts

The dynamic behavior of a system can be specified in statecharts,\ud and the activities of the system can be implemented in terms of\ud functions in the C programming language. Later, the statecharts\ud and the activities can be integrated to realize the system that\ud fulfils a given set of requirements.\ud \ud After the integration, the statecharts, the activities, and the\ud requirements are subject to change due to emerging necessities\ud such as bug fixes. Any change to any of these artifacts has a cost\ud in terms of effort, and risk of errors.\ud \ud In this paper, we provide a rigorous analysis of a relevant subset\ud of possible changes to activities, and their associated costs. In\ud addition, we present the overview of our solution to reduce these\ud costs.\u

Auto-coding UML statecharts for flight software

Statecharts have been used as a means to communicate behaviors in a precise manner between system engineers and software engineers. Handtranslating a statechart to code, as done on some previous space missions, introduces the possibility of errors in the transformation from chart to code. To improve auto-coding, we have developed a process that generates flight code from UML statecharts. Our process is being used for the flight software on the Space Interferometer Mission (SIM)