The TASTE Toolset: turning human designed heterogeneous systems into computer built homogeneous software.

The TASTE tool-set results from spin-off studies of the ASSERT project, which started in 2004 with the objective to propose innovative and pragmatic solutions to develop real-time software. One of the primary targets was satellite flight software, but it appeared quickly that their characteristics were shared among various embedded systems. The solutions that we developed now comprise a process and several tools ; the development process is based on the idea that real-time, embedded systems are heterogeneous by nature and that a unique UML-like language was not helping neither their construction, nor their validation. Rather than inventing yet another "ultimate" language, TASTE makes the link between existing and mature technologies such as Simulink, SDL, ASN.1, C, Ada, and generates complete, homogeneous software-based systems that one can straightforwardly download and execute on a physical target. Our current prototype is moving toward a marketed product, and sequel studies are already in place to support, among others, FPGA systems

Integrating security and usability into the requirements and design process

According to Ross Anderson, 'Many systems fail because their designers protect the wrong things or protect the right things in the wrong way'. Surveys also show that security incidents in industry are rising, which highlights the difficulty of designing good security. Some recent approaches have targeted security from the technological perspective, others from the human–computer interaction angle, offering better User Interfaces (UIs) for improved usability of security mechanisms. However, usability issues also extend beyond the user interface and should be considered during system requirements and design. In this paper, we describe Appropriate and Effective Guidance for Information Security (AEGIS), a methodology for the development of secure and usable systems. AEGIS defines a development process and a UML meta-model of the definition and the reasoning over the system's assets. AEGIS has been applied to case studies in the area of Grid computing and we report on one of these

Model-driven engineering approach to design and implementation of robot control system

In this paper we apply a model-driven engineering approach to designing domain-specific solutions for robot control system development. We present a case study of the complete process, including identification of the domain meta-model, graphical notation definition and source code generation for subsumption architecture -- a well-known example of robot control architecture. Our goal is to show that both the definition of the robot-control architecture and its supporting tools fits well into the typical workflow of model-driven engineering development.Comment: Presented at DSLRob 2011 (arXiv:cs/1212.3308

Trusted product lines

This thesis describes research undertaken into the application of software product line approaches to the development of high-integrity, embedded real-time software systems that are subject to regulatory approval/certification. The motivation for the research arose from a real business need to reduce cost and lead time of aerospace software development projects. The thesis hypothesis can be summarised as follows: It is feasible to construct product line models that allow the specification of required behaviour within a reference architecture that can be transformed into an effective product implementation, whilst enabling suitable supporting evidence for certification to be produced. The research concentrates on the following four main areas: 1. Construction of an argument framework in which the application of product line techniques to high-integrity software development can be assessed and critically reviewed. 2. Definition of a product-line reference architecture that can host components containing variation. 3. Design of model transformations that can automatically instantiate products from a set of components hosted within the reference architecture. 4. Identification of verification approaches that may provide evidence that the transformations designed in step 3 above preserve properties of interest from the product line model into the product instantiations. Together, these areas form the basis of an approach we term “Trusted Product Lines”. The approach has been evaluated and validated by deployment on a real aerospace project; the approach has been used to produce DO-178B/ED-12B Level A applications of over 300 KSLOC in size. The effect of this approach on the software development process has been critically evaluated in this thesis, both quantitatively (in terms of cost and relative size of process phases) and qualitatively (in terms of software quality). The “Trusted Product Lines” approach, as described within the thesis, shows how product line approaches can be applied to high-integrity software development, and how certification evidence created and arguments constructed for products instantiated from the product line. To the best of our knowledge, the development and effective application of product line techniques in a certification environment is novel and unique

Supporting a Multi-formalism Model Driven Development Process with Model Transformation, a TOPCASED implementation

International audienceThe ASSERT (Automated proof based System and Software Engineering for Real-Time Applications) European Integrated Project (IST-FP6-004033, http://www.assert-project.net/) defined and experimented a multi formalism Model Driven Engineering (MDE) process, enforcing an approach with separated specification and refinement of functional and non-functional properties.• Functional specification, design and development is based on UML profiles to support AADL concepts [2] and behavioural specification.• Real time Architecture properties are based on extensions targeting Ravenscar Computing execution Model (RCM see [6]) constraints upon component interface and ports.• Model transformation is supporting correctness preserving rules towards a Virtual Machine execution environment or a verification dedicated environment.A tool chain called IDEA (Integrated Development Environment for ASSERT) supporting the process was developed by the CS ASSERT team on top of the Eclipse/TOPCASED environment allowing:• Integrated use of several formalisms in a development life-cycle (UML, AADL, IF[4]) .• Model transformation from UML to IF, AADL to RCM and RCM to Ada• Automated code generationThe approach experimented allows combined use of best suited formalisms and features for MDE developments. The TOPCASED tool proved to be a unique integrated toolset for prototyping UML and meta models supporting tools.The main feedback gained from applying the notations and approach on small to medium case studies is that UML profiling is not scalable, and that use of several Domain Specific Languages (DSL) seems far more suitable. Semantic clashes can be limited by raising the abstraction level, and by partitioning properties for verification

Herramientas de análisis temporal para el desarrollo de sistemas de tiempo real críticos.

El presente documento describe la integración de herramientas para el análisis temporal en el conjunto de herramientas ASSERT. El proceso de desarrollo, el conjunto de herramientas y la máquina virtual de ASSERT se orientan al desarrollo de sistemas distribuidos empotrados de tiempo real con requisitos de fiabilidad muy exigentes. El enfoque del proyecto ASSERT es el de “convertir diseños heterogéneos realizados por el hombre en software homogéneo generado automáticamente”. Para ello utiliza el modelo computacional de Ravenscar, que es un modelo de concurrencia que permite el análisis estático del comportamiento de tiempo real. Por lo tanto, el uso de herramientas para el análisis de la planificabilidad y el cálculo del tiempo de cómputo en el peor caso es de importancia primordial. En este documento se detalla la adecuación de distintas herramientas a los sistemas distribuidos empotrados de tiempo real críticos, para su posterior integración en el proceso de desarroll

Safe software development for a video-based train detection system in accordance with EN 50128

Diese Studienarbeit gibt einen Überblick über ausgewählte Teile des Softwareentwicklungsprozesses für sicherheitsrelevante Applikationen am Beispiel eines videobasierten Zugerkennungssystems. Eine IP-Kamera und ein externer Bildverarbeitungscomputer wurden dazu mit einer speziell entworfenen, verteilten Software ausgestattet. Die in Ada und C geschriebenen Teile kommunizieren dabei über ein dediziertes, UDP-basiertes Netzwerkprotokoll. Beide Programme wurden intensiv anhand verschiedener Techniken analysiert, die in der Norm EN 50128 festgelegt sind, welche sich speziell an Software für Eisenbahnsteuerungs- und überwachungssysteme richtet. Eine an der Norm orientierte Struktur mit Verweisen auf die diskutierten Techniken zu Beginn eines jeden Abschnitts erlaubt einen schnellen Vergleich mit den originalen Anforderungen des Normtexts. Zusammenfassend haben sich die Techniken bis auf wenige Ausnahmen als sehr geeignet für die praktische Entwicklung von sicherer Software erwiesen. Allerdings entbindet die Norm durch ihre teils sehr abstrakten Anforderungen das am Projekt beteiligte Personal in keinster Weise von seiner individuellen Verantwortung. Entsprechend sind die hier vorgestellten Techniken für andere Projekte nicht ohne Anpassungen zu übernehmen.:1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Description of the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Real-time constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Camera type and output format . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Real-world constrains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Train Detection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 EN 50128 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Defensive Programming . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2 Fully Defined Interface . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.4 Error Detecting and Correcting Codes . . . . . . . . . . . . . . . . 29 3.1.5 Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.6 Alternative optionally required measures . . . . . . . . . . . . . . 34 3.2 Software Design and Implementation . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.4 Design and Coding Standards . . . . . . . . . . . . . . . . . . . . 39 3.2.5 Strongly Typed Programming Languages . . . . . . . . . . . . . . 41 3.2.6 Alternative optionally required measures . . . . . . . . . . . . . . 44 3.3 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48This paper intends to give an overview of selected parts of the software development process for safety-relevant applications using the example of a video-based train detection. An IP-camera and an external image processing computer were equipped with a custom-built, distributed software system. Written in Ada and C, the system parts communicate via a dedicated UDP-based protocol. Both programs were subject to intense analysis according to measures laid down in the EN 50128 standard specifically targeted at software for railway control and protection systems. Preceding each section, a structure resembling the standard document with references to the discussed measures allows for easy comparison with the original requirements of EN 50128. In summary, the techniques have proven to be very suitable for practical safe software development in all but very few edge-cases. However, the highly abstract descriptive level of the standard requires the staff involved to accept an enormous personal responsibility throughout the entire development process. The specific measures carried out for this project may therefore not be equally applicable elsewhere.:1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Description of the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 Real-time constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Safety requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Camera type and output format . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Real-world constrains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Train Detection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 EN 50128 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Defensive Programming . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2 Fully Defined Interface . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.4 Error Detecting and Correcting Codes . . . . . . . . . . . . . . . . 29 3.1.5 Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.6 Alternative optionally required measures . . . . . . . . . . . . . . 34 3.2 Software Design and Implementation . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Structured Methodology . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.3 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.4 Design and Coding Standards . . . . . . . . . . . . . . . . . . . . 39 3.2.5 Strongly Typed Programming Languages . . . . . . . . . . . . . . 41 3.2.6 Alternative optionally required measures . . . . . . . . . . . . . . 44 3.3 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Open-DO: Open Framework for Critical Systems

Critical systems development pushes software quality to the extreme. When human life depends on the correct operation of the software, strict processes are put in place to ensure, as much as possible, the absence of errors in the airborne system. These processes are very tool-demanding, and these tools also need to follow stringent and rigorous guidelines to provide the proper guarantees of quality. The Open-DO initiative aims at providing a framework federating open-source tools for safety-critical systems. A key point is that these tools will come with the material to ensure that industrial users can trust their output and use them to develop software compliant to the highest integrity levels