38 research outputs found

    Communication Paradigms for High-Integrity Distributed Systems with Hard Real-Time Requirements

    Get PDF
    The development and maintenance of high-integrity software is very expensive, and a specialized development process is required due to its distinctive characteristics. Namely, safety-critical systems usually execute over a distributed embedded platform with few hardware resources which must provide real-time communication and fault-tolerance. This work discusses the adequate communication paradigms for high-integrity distributed applications with hard real-time requirements, and proposes a restricted middleware based on the current schedulability theory which can be certified and capable to obtain the required predictability and timeliness of this kind of systems

    Run-Time Monitoring Environments for Real-Time and Safety Critical Systems

    Get PDF
    Demo in Demo Session, 22nd IEEE Real-Time Embedded Technology & Applications Symposium (RTAS 2016). 11 to 14, Apr, 2016. Austria.In this work, we present four different implementations of a run-time monitoring framework suited to real-time and safety critical systems. Two implementations are written in Ada and follow the Ravenscar profile, which make them particularly suited to the development of high integrity systems. The first version is available as a standalone library for Ada programs while the second has been integrated in the GNAT run-time environment and instruments the ORK+ micro-kernel. Information on the task scheduling events, directly originating from the kernel, can thus be used by the monitors to check if the system follows all its requirements. The third implementation is a standalone library written in C++ that can be used in any POSIX compliant run-time environment. It is therefore compatible with the vast majority of operating systems used in embedded systems. The last implementation is a loadable kernel module for Linux. It has for main advantage to be able to enforce complete space partitioning between the monitors and the monitored applications. It is therefore impossible for memory faults to propagate and corrupt the state of the monitors.info:eu-repo/semantics/publishedVersio

    ARINC-653 Inter-partition communications and the ravenscar profile

    Full text link
    The ARINC-653 standard is often used to build mixed-criticality systems, using a partitioned architecture. Inter-partition communication is carried out by means of a message-passing mechanism based on ports. The standard includes an API for Ada, but the implementation semantics of operation ports is not fully defined. Furthermore, the API was defined for the Ada 95 standard, and therefore does not take into account the enhancements to the real-time features of the language that have been incorporated in the 2005 and 2013 standards, most notably the Ravenscar profile. This paper is aimed at clarifying the implementation of ARINC communication ports in Ada and the Ravenscar profile. ARINC communication ports are analysed, and their compatibility with the Ravenscar profile is assessed. A new API that can be used with the profile is defined, and a pilot implementation is introduced

    Ravenscar computational model compliant AADL simulation on LEON2

    Get PDF
    AADL has been proposed for designing and analyzing SW and HW architectures for real-time mission-critical embedded systems. Although the Behavioral Annex improves its simulation semantics, AADL is a language for analyzing architectures and not for simulating them. AADS-T is an AADL simulation tool that supports the performance analysis of the AADL specification throughout the refinement process from the initial system architecture until the complete, detailed application and execution platform are developed. In this way, AADS-T enables the verification of the initial timing constraints during the complete design process. In this paper we focus on the compatibility of AADS-T with the Ravenscar Computational Model (RCM) as part of the TASTE toolset. Its flexibility enables AADS-T to support different processors. In this work we have focused on performing the simulation on a LEON2 processor.This work has been supported by ESTEC 22810/09/NL/JK HW-SW CODESIGN Project contracted to GMV Aerospace and Defence S.A.U

    A non-intrusive fault tolerant framework for mission critical real-time systems

    Get PDF
    Thesis (S.M.)--Massachusetts Institute of Technology, Dept. of Aeronautics and Astronautics, 2005.Includes bibliographical references (p. 85-87).The need for dependable real-time systems for embedded application is growing, and, at the same time, so does the amount of functionality required from these systems. As testing can only show the presence of errors, not their absence, higher levels of system dependability may be provided by the implementation of mechanisms that can protect the system from faults. We present a framework for the development of fault tolerant mission critical real-time systems that provides a structure for flexible, efficient and deterministic design. The framework leverages three key knowledge domains: firstly, a software concurrency model, the Ada Ravenscar Profile, which guarantees deterministic behavior; secondly, the design of a hardware scheduler, the RavenHaRT kernel, which further provides deadlock free inter-task communication management; and finally, the design of a hardware execution time monitor, the Monitoring Chip, which provides non-intrusive error detection. To increase service dependability, we propose a fault tolerance strategy that uses multiple operating modes to provide system-level handling of timing errors. The hierarchical set of operating modes offers different gracefully degraded levels of guaranteed service. This approach relies on the elements of the framework discussed above and is illustrated through a sample case study of a generic navigation system.by Sébastien Gorelov.S.M

    Ravenscar cross compiler for the Gurkh Project

    Get PDF
    Thesis (M. Eng.)--Massachusetts Institute of Technology, Dept. of Electrical Engineering and Computer Science, 2004.Includes bibliographical references (leaves 54-56).Concurrency has greatly simplified the design of embedded software, but the gain in design simplicity is offset by the complexity of system implementation. The Ravenscar profile of Ada95 defines safe tasking constructs that enable the use of deterministic concurrency. The translation of these high-level constructs by the compiler to deterministic object code is dependent on both the underlying operating system and the system operation platform. The commonly available open-source development tools for compiling Ravenscar compliant Ada95 assume that the operating system is implemented as software. A hardware implemented run-time kernel requires a radical rethink of the execution architecture because operating system calls have to be routed from the host processor running the tasks to the hardware implemented kernel RavenHaRT. The redesigned compiler pGNAT is based on the open-source GNAT compiler and uses the GCC back end to cross compile application code to PowerPC object code. The GNAT run-time library (GNARL) is modified to support the use of RavenHaRT. This thesis presents the technical challenges faced and the modifications carried out for generating RavenHaRT compatible, Ravenscar compliant object code.by Pee Seeumpornroj.M.Eng

    The Ravenscar-compliant hardware run-time (Ravenhart) kernel

    Get PDF
    Thesis (S.M.)--Massachusetts Institute of Technology, Dept. of Aeronautics and Astronautics, 2004.Includes bibliographical references (leaves 69-71).Real-time embedded systems are increasingly becoming the foundation of control systems in both the aerospace and automotive worlds. This class of systems has to meet three requirements: strict timing constraints on operational behavior, limited resource availability, and stringent certification standards. The heart of any embedded system is its run-time system (RTS), which provides resource management, task creation and deletion, and manages inter-task communication. The traditional Ada RTS does not provide deterministic behavior. In order to meet the requirement of a minimal, deterministic RTS, a formal model based on the Ravenscar profile of Ada95 was developed by Professor Kristina Lundqvist in 2000. This formal model forms the basis of the work carried out in this thesis. This thesis aims to leverage the reliability and efficiency of programmable hardware to implement a run-time kernel called RavenHaRT. The kernel was designed to support Ravenscar compliant Ada95 code and provides task creation, task scheduling and inter-task communication capabilities. The timing properties embedded in the formal model are captured in terms of kernel performance within the hardware. The kernel was implemented using a Xilinx Virtex-II Pro FPGA. The results from testing demonstrate that the hardware kernel has the expected behavior and can interface correctly with software code.by Anna Silbovitz.S.M

    Experience in spacecraft on-board software development

    Get PDF
    This paper describes some important aspects of high- integrity software development based on the authors' work. Current group research is oriented towards mixed- criticality partitioned systems, development tools, real- time kernels, and language features. The UPMSat-2 satellite software is being used as technology demonstra- tor and a case study for the assessment of the research results. The flight software that will run on the satellite is based on proven technology, such as GNAT/ORK+ and LEON3. There is an experimental version that is being built using a partitioned approach, aiming at assessing a toolset targeting partitioned multi-core em- bedded systems. The singularities of both approaches are discussed, as well as some of the tools that are being used for developing the software

    Enabling Ada and OpenMP runtimes interoperability through template-based execution

    Get PDF
    The growing trend to support parallel computation to enable the performance gains of the recent hardware architectures is increasingly present in more conservative domains, such as safety-critical systems. Applications such as autonomous driving require levels of performance only achievable by fully leveraging the potential parallelism in these architectures. To address this requirement, the Ada language, designed for safety and robustness, is considering to support parallel features in the next revision of the standard (Ada 202X). Recent works have motivated the use of OpenMP, a de facto standard in high-performance computing, to enable parallelism in Ada, showing the compatibility of the two models, and proposing static analysis to enhance reliability. This paper summarizes these previous efforts towards the integration of OpenMP into Ada to exploit its benefits in terms of portability, programmability and performance, while providing the safety benefits of Ada in terms of correctness. The paper extends those works proposing and evaluating an application transformation that enables the OpenMP and the Ada runtimes to operate (under certain restrictions) as they were integrated. The objective is to allow Ada programmers to (naturally) experiment and evaluate the benefits of parallelizing concurrent Ada tasks with OpenMP while ensuring the compliance with both specifications.This work was supported by the Spanish Ministry of Science and Innovation under contract TIN2015-65316-P, by the European Union’s Horizon 2020 Research and Innovation Programme under grant agreements no. 611016 and No 780622, and by the FCT (Portuguese Foundation for Science and Technology) within the CISTER Research Unit (CEC/04234).Peer ReviewedPostprint (published version

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

    Get PDF
    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
    corecore