Analysis of System-Failure Rate Caused by Soft-Errors using a UML-Based Systematic Methodology in an SoC

This paper proposes an analytical method to assess the soft-error rate (SER) in the early stages of a System-on-Chip (SoC) platform-based design methodology. The proposed method gets an executable UML (Unified Modeling Language) model of the SoC and the raw soft- error rate of different parts of the platform as its inputs. Soft-errors on the design are modeled by disturbances on the value of attributes in the classes of the UML model and disturbances on opcodes of software cores. The Dynamic behavior of each core is used to determine the propagation probability of each variable disturbance to the core outputs. Furthermore, the SER and the execution time of each core in the SoC and a Failure Modes and Effects Analysis (FMEA) that determines the severity of each failure mode in the SoC are used to compute the System-Failure Rate (SFR) of the So

Models for Paired Comparison Data: A Review with Emphasis on Dependent Data

Thurstonian and Bradley-Terry models are the most commonly applied models in the analysis of paired comparison data. Since their introduction, numerous developments have been proposed in different areas. This paper provides an updated overview of these extensions, including how to account for object- and subject-specific covariates and how to deal with ordinal paired comparison data. Special emphasis is given to models for dependent comparisons. Although these models are more realistic, their use is complicated by numerical difficulties. We therefore concentrate on implementation issues. In particular, a pairwise likelihood approach is explored for models for dependent paired comparison data, and a simulation study is carried out to compare the performance of maximum pairwise likelihood with other limited information estimation methods. The methodology is illustrated throughout using a real data set about university paired comparisons performed by students.Comment: Published in at http://dx.doi.org/10.1214/12-STS396 the Statistical Science (http://www.imstat.org/sts/) by the Institute of Mathematical Statistics (http://www.imstat.org

Performance assessment of an architecture with adaptative interfaces for people with special needs

People in industrial societies carry more and more portable electronic devices (e.g., smartphone or console) with some kind of wireles connectivity support. Interaction with auto-discovered target devices present in the environment (e.g., the air conditioning of a hotel) is not so easy since devices may provide inaccessible user interfaces (e.g., in a foreign language that the user cannot understand). Scalability for multiple concurrent users and response times are still problems in this domain. In this paper, we assess an interoperable architecture, which enables interaction between people with some kind of special need and their environment. The assessment, based on performance patterns and antipatterns, tries to detect performance issues and also tries to enhance the architecture design for improving system performance. As a result of the assessment, the initial design changed substantially. We refactorized the design according to the Fast Path pattern and The Ramp antipattern. Moreover, resources were correctly allocated. Finally, the required response time was fulfilled in all system scenarios. For a specific scenario, response time was reduced from 60 seconds to less than 6 seconds

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

A study of the Rapid Maxillary Expansion with the use of the finite element method

EThOS - Electronic Theses Online ServiceGBUnited Kingdo

Re-use of tests and arguments for assesing dependable mixed-critically systems

The safety assessment of mixed-criticality systems (MCS) is a challenging activity due to system heterogeneity, design constraints and increasing complexity. The foundation for MCSs is the integrated architecture paradigm, where a compact hardware comprises multiple execution platforms and communication interfaces to implement concurrent functions with different safety requirements. Besides a computing platform providing adequate isolation and fault tolerance mechanism, the development of an MCS application shall also comply with the guidelines defined by the safety standards. A way to lower the overall MCS certification cost is to adopt a platform-based design (PBD) development approach. PBD is a model-based development (MBD) approach, where separate models of logic, hardware and deployment support the analysis of the resulting system properties and behaviour. The PBD development of MCSs benefits from a composition of modular safety properties (e.g. modular safety cases), which support the derivation of mixed-criticality product lines. The validation and verification (V&V) activities claim a substantial effort during the development of programmable electronics for safety-critical applications. As for the MCS dependability assessment, the purpose of the V&V is to provide evidences supporting the safety claims. The model-based development of MCSs adds more V&V tasks, because additional analysis (e.g., simulations) need to be carried out during the design phase. During the MCS integration phase, typically hardware-in-the-loop (HiL) plant simulators support the V&V campaigns, where test automation and fault-injection are the key to test repeatability and thorough exercise of the safety mechanisms. This dissertation proposes several V&V artefacts re-use strategies to perform an early verification at system level for a distributed MCS, artefacts that later would be reused up to the final stages in the development process: a test code re-use to verify the fault-tolerance mechanisms on a functional model of the system combined with a non-intrusive software fault-injection, a model to X-in-the-loop (XiL) and code-to-XiL re-use to provide models of the plant and distributed embedded nodes suited to the HiL simulator, and finally, an argumentation framework to support the automated composition and staged completion of modular safety-cases for dependability assessment, in the context of the platform-based development of mixed-criticality systems relying on the DREAMS harmonized platform.La dificultad para evaluar la seguridad de los sistemas de criticidad mixta (SCM) aumenta con la heterogeneidad del sistema, las restricciones de diseño y una complejidad creciente. Los SCM adoptan el paradigma de arquitectura integrada, donde un hardware embebido compacto comprende múltiples plataformas de ejecución e interfaces de comunicación para implementar funciones concurrentes y con diferentes requisitos de seguridad. Además de una plataforma de computación que provea un aislamiento y mecanismos de tolerancia a fallos adecuados, el desarrollo de una aplicación SCM además debe cumplir con las directrices definidas por las normas de seguridad. Una forma de reducir el coste global de la certificación de un SCM es adoptar un enfoque de desarrollo basado en plataforma (DBP). DBP es un enfoque de desarrollo basado en modelos (DBM), en el que modelos separados de lógica, hardware y despliegue soportan el análisis de las propiedades y el comportamiento emergente del sistema diseñado. El desarrollo DBP de SCMs se beneficia de una composición modular de propiedades de seguridad (por ejemplo, casos de seguridad modulares), que facilitan la definición de líneas de productos de criticidad mixta. Las actividades de verificación y validación (V&V) representan un esfuerzo sustancial durante el desarrollo de aplicaciones basadas en electrónica confiable. En la evaluación de la seguridad de un SCM el propósito de las actividades de V&V es obtener las evidencias que apoyen las aseveraciones de seguridad. El desarrollo basado en modelos de un SCM incrementa las tareas de V&V, porque permite realizar análisis adicionales (por ejemplo, simulaciones) durante la fase de diseño. En las campañas de pruebas de integración de un SCM habitualmente se emplean simuladores de planta hardware-in-the-loop (HiL), en donde la automatización de pruebas y la inyección de faltas son la clave para la repetitividad de las pruebas y para ejercitar completamente los mecanismos de tolerancia a fallos. Esta tesis propone diversas estrategias de reutilización de artefactos de V&V para la verificación temprana de un MCS distribuido, artefactos que se emplearán en ulteriores fases del desarrollo: la reutilización de código de prueba para verificar los mecanismos de tolerancia a fallos sobre un modelo funcional del sistema combinado con una inyección de fallos de software no intrusiva, la reutilización de modelo a X-in-the-loop (XiL) y código a XiL para obtener modelos de planta y nodos distribuidos aptos para el simulador HiL y, finalmente, un marco de argumentación para la composición automatizada y la compleción escalonada de casos de seguridad modulares, en el contexto del desarrollo basado en plataformas de sistemas de criticidad mixta empleando la plataforma armonizada DREAMS.Kritikotasun nahastuko sistemen segurtasun ebaluazioa jarduera neketsua da beraien heterogeneotasuna dela eta. Sistema hauen oinarria arkitektura integratuen paradigman datza, non hardware konpaktu batek exekuzio plataforma eta komunikazio interfaze ugari integratu ahal dituen segurtasun baldintza desberdineko funtzio konkurrenteak inplementatzeko. Konputazio plataformek isolamendu eta akatsen aurkako mekanismo egokiak emateaz gain, segurtasun arauek definituriko jarraibideak jarraitu behar dituzte kritikotasun mistodun aplikazioen garapenean. Sistema hauen zertifikazio prozesuaren kostua murrizteko aukera bat plataformetan oinarritutako garapenean (PBD) datza. Garapen planteamendu hau modeloetan oinarrituriko garapena da (MBD) non modeloaren logika, hardware eta garapen desberdinak sistemaren propietateen eta portaeraren aurka aztertzen diren. Kritikotasun mistodun sistemen PBD garapenak etekina ateratzen dio moduluetan oinarrituriko segurtasun propietateei, adibidez: segurtasun kasu modularrak (MSC). Modulu hauek kritikotasun mistodun produktu-lerroak ere hartzen dituzte kontutan. Berifikazio eta balioztatze (V&V) jarduerek esfortzu kontsideragarria eskatzen dute segurtasun-kiritikoetarako elektronika programagarrien garapenean. Kritikotasun mistodun sistemen konfiantzaren ebaluazioaren eta V&V jardueren helburua segurtasun eskariak jasotzen dituzten frogak proportzionatzea da. Kritikotasun mistodun sistemen modelo bidezko garapenek zeregin gehigarriak atxikitzen dizkio V&V jarduerari, fase honetan analisi gehigarriak (hots, simulazioak) zehazten direlako. Bestalde, kritikotasun mistodun sistemen integrazio fasean, hardware-in-the-loop (Hil) simulazio plantek V&V iniziatibak sostengatzen dituzte non testen automatizazioan eta akatsen txertaketan funtsezko jarduerak diren. Jarduera hauek frogen errepikapena eta segurtasun mekanismoak egiaztzea ahalbidetzen dute. Tesi honek V&V artefaktuen berrerabilpenerako estrategiak proposatzen ditu, kritikotasun mistodun sistemen egiaztatze azkarrerako sistema mailan eta garapen prozesuko azken faseetaraino erabili daitezkeenak. Esate baterako, test kodearen berrabilpena akats aurkako mekanismoak egiaztatzeko, modelotik X-in-the-loop (XiL)-ra eta kodetik XiL-rako konbertsioa HiL simulaziorako eta argumentazio egitura bat DREAMS Europear proiektuan definituriko arkitektura estiloan oinarrituriko segurtasun kasu modularrak automatikoki eta gradualki sortzeko