DOCSLIB.ORG

Coverity Support for MISRA Coding Standards

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Coverity Support for MISRA Coding Standards Fully ensure the safety, Overview reliability, and security Software is eating the world. Industries that have traditionally relied on mechanical, of software written in C electronic, and analog control systems are increasingly replacing them with software- and C++ driven systems. For example, the average car is expected to contain 300 million lines of code in the next decade—up from 100 million lines of code today. But with the growth of software comes the growth of software defects—which can manifest themselves in these systems with tangible and life-threatening consequences. More importantly, malicious actors can deliberately trigger failures for their own purposes. Highly complex industries involve many vendors and suppliers simultaneously contributing to the software that goes into the final product. Every participant in this software supply chain must reach consensus on coding standards, defect reporting structures, and so on. The confluence of these two factors—increasing complexity in software systems and longer software supply chains—creates the demand for new tools. The MISRA C and C++ coding standards are widely used in safety-critical industries, such as automotive, medical, military, and aerospace. The standards provide a set of best practices for writing C and C++ code, facilitating the authorship of safe, secure, and portable code. With Coverity® static analysis, Synopsys provides a comprehensive solution for MISRA standard compliance that is scalable from individual developers all the way to complex software supply chains. | synopsys.com | 1 MISRA C:2004 MISRA C:2004 rule coverage The MISRA C:2004 coding standard supports the C90 language specification. Supported All Percent coverage It was first released in 2004 and consists All 130 142 91.5% of 142 rules: 124 required and 18 advisory. Coverity covers the entire MISRA C:2004 Required 113 124 91.1% standard.* Advisory 17 18 94.4% * All rules that can be checked by static analysis are supported. MISRA C:2004 contains 12 rules that are not statically checkable, so a total of 130 are implemented (out of 142). MISRA C:2004 supported rules Rule Rule name Category Supported Notes All code shall conform to ISO/IEC 9899:1990 “Programming languages — C”, amended and corrected by ISO/IEC 9899/ Rule 1.1 Required Yes COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/ COR2:1996. No reliance shall be placed on undefined or unspecified Rule 1.2 Required No behaviour. Multiple compilers and/or languages shall only be used if there This rule is not statically Rule 1.3 is a common defined interface standard for object code to Required No verifiable. which the languages/compilers/assemblers conform. The compiler/linker shall be checked to ensure that 31 character This rule is not statically Rule 1.4 significance and case sensitivity are supported for external Required No verifiable. identifiers. Floating-point implementations should comply with a defined This rule is not statically Rule 1.5 Required No floating-point standard. verifiable. Rule 2.1 Assembly language shall be encapsulated and isolated. Required Yes Rule 2.2 Source code shall only use /* ... */ style comments. Required Yes Rule 2.3 The character sequence /* shall not be used within a comment. Required Yes Rule 2.4 Sections of code should not be “commented out”. Advisory Yes All usage of implementation-defined behaviour shall be This rule is not statically Rule 3.1 Required No documented. verifiable. The character set and the corresponding encoding shall be This rule is not statically Rule 3.2 Required No documented. verifiable. The implementation of integer division in the chosen compiler This rule is not statically Rule 3.3 Advisory No should be determined, documented and taken into account. verifiable. All uses of the #pragma directive shall be documented and This rule is not statically Rule 3.4 Required No explained. verifiable. If it is being relied upon, the implementation defined behaviour This rule is not statically Rule 3.5 Required No and packing of bitfields shall be documented. verifiable. All libraries used in production code shall be written to comply This rule is not statically Rule 3.6 with the provisions of this document, and shall have been Required No verifiable. subject to appropriate validation. Only those escape sequences that are defined in the ISO C Rule 4.1 Required Yes standard shall be used. Rule 4.2 Trigraphs shall not be used. Required Yes | synopsys.com | 2 Rule Rule name Category Supported Notes Identifiers (internal and external) shall not rely on the Rule 5.1 Required Yes significance of more than 31 characters. Identifiers in an inner scope shall not use the same name as an Rule 5.2 Required Yes identifier in an outer scope, and therefore hide that identifier. Rule 5.3 A typedef name shall be a unique identifier. Required Yes Rule 5.4 A tag name shall be a unique identifier. Required Yes No object or function identifier with static storage duration Rule 5.5 Advisory Yes should be reused. No identifier in one name space should have the same spelling Rule 5.6 as an identifier in another name space, with the exception of Advisory Yes structure member and union member names. Rule 5.7 No identifier name should be reused. Advisory Yes The plain char type shall be used only for the storage and use of Rule 6.1 Required Yes character values. signed and unsigned char type shall be used only for the storage Rule 6.2 Required Yes and use of numeric values. typedefs that indicate size and signedness should be used in Rule 6.3 Advisory Yes place of the basic numerical types. Bit fields shall only be defined to be of type unsigned int or Rule 6.4 Required Yes signed int. Rule 6.5 Bit fields of signed type shall be at least 2 bits long. Required Yes Octal constants (other than zero) and octal escape sequences Rule 7.1 Required Yes shall not be used. Functions shall have prototype declarations and the prototype Rule 8.1 Required Yes shall be visible at both the function definition and call. Whenever an object or function is declared or defined, its type Rule 8.2 Required Yes shall be explicitly stated. For each function parameter the type given in the declaration Rule 8.3 and definition shall be identical, and the return types shall also Required Yes be identical. If objects or functions are declared more than once their types Rule 8.4 Required Yes shall be compatible. There shall be no definitions of objects or functions in a header Rule 8.5 Required Yes file. Rule 8.6 Functions shall be declared at file scope. Required Yes Objects shall be defined at block scope if they are only accessed Rule 8.7 Required Yes from within a single function. An external object or function shall be declared in one and only Rule 8.8 Required Yes one file. An identifier with external linkage shall have exactly one external Rule 8.9 Required Yes definition. All declarations and definitions of objects or functions at file Rule 8.10 scope shall have internal linkage unless external linkage is Required Yes required. The static storage class specifier shall be used in definitions and Rule 8.11 Required Yes declarations of objects and functions that have internal linkage. When an array is declared with external linkage, its size shall be Rule 8.12 Required Yes stated explicitly or defined implicitly by initialisation. All automatic variables shall have been assigned a value before Rule 9.1 Required Yes being used. | synopsys.com | 3 Rule Rule name Category Supported Notes Braces shall be used to indicate and match the structure in the Rule 9.2 Required Yes non-zero initialisation of arrays and structures. In an enumerator list, the “=” construct shall not be used to Rule 9.3 explicitly initialise members other than the first, unless all items Required Yes are explicitly initialised. The value of an expression of integer type shall not be implicitly converted to a different underlying type if: (a) it is not a conversion to a wider integer type of the same signedness, or (b) Rule 10.1 Required Yes signedness, or the expression is complex, or (c) the expression is not constant and is a function argument, or (d) the expression is not constant and is a return expression. The value of an expression of floating type shall not be implicitly converted to a different type if: (a) it is not a conversion to a Rule 10.2 wider floating type, or (b) the expression is complex, or (c) the Required Yes expression is a function argument, or (d) the expression is a return expression. The value of a complex expression of integer type shall only be Rule 10.3 cast to a type of the same signedness that is no wider than the Required Yes underlying type of the expression. The value of a complex expression of floating type shall only be Rule 10.4 Required Yes cast to a floating type that is narrower or of the same size. If the bitwise operators ~ and << are applied to an operand of Rule 10.5 underlying type unsigned char or unsigned short, the result shall Required Yes be immediately cast to the underlying type of the operand. Rule 10.6 A “U” suffix shall be applied to all constants of unsigned type. Required Yes Conversions shall not be performed between a pointer to a Rule 11.1 Required Yes function and any type other than an integral type. Conversions shall not be performed between a pointer to object Rule 11.2 and any type other than an integral type, another pointer to Required Yes object type or a pointer to void.
Recommended publications
  • Language Subsetting in an Industrial Context: a Comparison of MISRA C 1998 and MISRA C 2004

    Language Subsetting in an Industrial Context: a Comparison of MISRA C 1998 and MISRA C 2004

    Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C 2004 Les Hatton CISM, University of Kingston∗ November 20, 2005 Abstract The MISRA C standard [7] first appeared in 1998 with the objective of providing a set of guidelines to restrict features in the ISO C language of known undefined or otherwise dangerous behaviour. The standard was assembled by representatives of a number of companies in the automobile sector in response to the rapidly growing use of C in electronic embedded systems in automobiles. The standard attempts to build on the earlier work of [6], [3] and others. Due to various perceived deficiencies, notably considerable ambiguity in the rule definitions, a revision was planned and eventually appeared in 2004. This paper measures how well the two stan- dards compare on the same population of software and also determines how well the 2004 version achieved its stated goals. Given its increasing influence, the results raise important concerns. Keywords: safer subsets, MISRA C, embedded control systems 1 Overview Pragmatic safer subsetting of languages to remove dependence on poorly defined features is finally becoming a mainstream activity with the recent recommen- dation to form a high-integrity study group under the auspices of the ISO, [8] with the intention of producing sets of rules to restrict features with undefined or otherwise dangerous behaviour in programming languages in common use. It frequently comes as a surprise to developers that significant parts of a pro- gramming language can fall into this category. In practice, all standardised programming languages contain problematic features for a variety of reasons which include the inability of the standardising committee to agree on the be- haviour of a particular feature, the use of unintentionally ambiguous language in the standards document itself, omitting to say anything at all and so on.
  • Lecture Notes on Types for Part II of the Computer Science Tripos

    Lecture Notes on Types for Part II of the Computer Science Tripos

    Q Lecture Notes on Types for Part II of the Computer Science Tripos Prof. Andrew M. Pitts University of Cambridge Computer Laboratory c 2016 A. M. Pitts Contents Learning Guide i 1 Introduction 1 2 ML Polymorphism 6 2.1 Mini-ML type system . 6 2.2 Examples of type inference, by hand . 14 2.3 Principal type schemes . 16 2.4 A type inference algorithm . 18 3 Polymorphic Reference Types 25 3.1 The problem . 25 3.2 Restoring type soundness . 30 4 Polymorphic Lambda Calculus 33 4.1 From type schemes to polymorphic types . 33 4.2 The Polymorphic Lambda Calculus (PLC) type system . 37 4.3 PLC type inference . 42 4.4 Datatypes in PLC . 43 4.5 Existential types . 50 5 Dependent Types 53 5.1 Dependent functions . 53 5.2 Pure Type Systems . 57 5.3 System Fw .............................................. 63 6 Propositions as Types 67 6.1 Intuitionistic logics . 67 6.2 Curry-Howard correspondence . 69 6.3 Calculus of Constructions, lC ................................... 73 6.4 Inductive types . 76 7 Further Topics 81 References 84 Learning Guide These notes and slides are designed to accompany 12 lectures on type systems for Part II of the Cambridge University Computer Science Tripos. The course builds on the techniques intro- duced in the Part IB course on Semantics of Programming Languages for specifying type systems for programming languages and reasoning about their properties. The emphasis here is on type systems for functional languages and their connection to constructive logic. We pay par- ticular attention to the notion of parametric polymorphism (also known as generics), both because it has proven useful in practice and because its theory is quite subtle.
  • Open C++ Tutorial∗

    Open C++ Tutorial∗

    Open C++ Tutorial∗ Shigeru Chiba Institute of Information Science and Electronics University of Tsukuba [email protected] Copyright c 1998 by Shigeru Chiba. All Rights Reserved. 1 Introduction OpenC++ is an extensible language based on C++. The extended features of OpenC++ are specified by a meta-level program given at compile time. For dis- tinction, regular programs written in OpenC++ are called base-level programs. If no meta-level program is given, OpenC++ is identical to regular C++. The meta-level program extends OpenC++ through the interface called the OpenC++ MOP. The OpenC++ compiler consists of three stages: preprocessor, source-to-source translator from OpenC++ to C++, and the back-end C++ com- piler. The OpenC++ MOP is an interface to control the translator at the second stage. It allows to specify how an extended feature of OpenC++ is translated into regular C++ code. An extended feature of OpenC++ is supplied as an add-on software for the compiler. The add-on software consists of not only the meta-level program but also runtime support code. The runtime support code provides classes and functions used by the base-level program translated into C++. The base-level program in OpenC++ is first translated into C++ according to the meta-level program. Then it is linked with the runtime support code to be executable code. This flow is illustrated by Figure 1. The meta-level program is also written in OpenC++ since OpenC++ is a self- reflective language. It defines new metaobjects to control source-to-source transla- tion. The metaobjects are the meta-level representation of the base-level program and they perform the translation.
  • Assignment 6: Subtyping and Bidirectional Typing

    Assignment 6: Subtyping and Bidirectional Typing

    Assignment 6: Subtyping and Bidirectional Typing 15-312: Foundations of Programming Languages Joshua Dunfield ([email protected]) Out: Thursday, October 24, 2002 Due: Thursday, November 7 (11:59:59 pm) 100 points total + (up to) 20 points extra credit 1 Introduction In this assignment, you will implement a bidirectional typechecker for MinML with , , +, 1, 0, , , and subtyping with base types int and float. ! ∗ 8 9 Note: In the .sml files, most changes from Assignment 4 are indicated like this: (* new asst6 code: *) ... (* end asst6 code *) 2 New in this assignment Some things have become obsolete (and have either been removed or left • in a semi-supported state). Exceptions and continuations are no longer “officially” supported. One can now (and sometimes must!) write type annotations e : τ. The • abstract syntax constructor is called Anno. The lexer supports shell-style comments in .mml source files: any line • beginning with # is ignored. There are now two valid syntaxes for functions, the old syntax fun f (x:t1):t2 is e end • and a new syntax fun f(x) is e end. Note the lack of type anno- tations. The definition of the abstract syntax constructor Fun has been changed; its arguments are now just bindings for f and x and the body. It no longer takes two types. 1 The old syntax fun f(x:t1):t2 is e end is now just syntactic sugar, transformed by the parser into fun f(x) is e end : t1 -> t2. There are floating point numbers, written as in SML. There is a new set of • arithmetic operators +., -., *., ˜.
  • MISRA-C Subset of the C Language for Critical Systems SAFETY-CRITICAL SYSTEMS

    MISRA-C Subset of the C Language for Critical Systems SAFETY-CRITICAL SYSTEMS

    MISRA-C Subset of the C language for critical systems SAFETY-CRITICAL SYSTEMS System is safety-critical if people might die due to software bugs Examples Automobile stability / traction control Medical automation Many military applications You develop safety-critical software differently from non-critical software MISRA-C MISRA – Motor Industry Software Reliability Association Their bright idea: Can’t avoid C But can force developers to avoid features of C that are known to be problematic Some language flaws Some legitimate features that happen to be bad for embedded software Most of MISRA-C is just good common sense for any C programmer TERMINOLOGY Execution error: Something illegal done by a program Out-of-bounds array reference Divide by zero Uninitialized variable usage Trapped execution error: Immediately results in exception or program termination Untrapped execution error: Program keeps running But may fail in an unexpected way later on E.g., due to corrupted RAM In C, operations with undefined behavior are not trapped SAFETY A safe language does not allow untrapped execution errors A statically safe language catches all execution errors at compile time Useful languages can’t be completely statically safe Java is dynamically safe C and C++ are very unsafe MISRA C is not safe either However, adherence to MISRA-C can largely be statically checked This eliminates or reduces the likelihood of some kinds of untrapped execution errors MISRA-C RULE 1.2 No reliance shall be placed on undefined or unspecified behavior. Lots of things in C have undefined behavior Divide by zero Out-of-bounds memory access Signed integer overflow Lots of things in C have implementation-defined and unspecified behavior printf (“a”) + printf (“b”); Both of these hard to detect at compile time, in general Implementation-defined behavior is fine in MISRA-C Why? MISRA-C RULE 5.2 Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.
  • Let's Get Functional

    Let's Get Functional

    5 LET’S GET FUNCTIONAL I’ve mentioned several times that F# is a functional language, but as you’ve learned from previous chapters you can build rich applications in F# without using any functional techniques. Does that mean that F# isn’t really a functional language? No. F# is a general-purpose, multi paradigm language that allows you to program in the style most suited to your task. It is considered a functional-first lan- guage, meaning that its constructs encourage a functional style. In other words, when developing in F# you should favor functional approaches whenever possible and switch to other styles as appropriate. In this chapter, we’ll see what functional programming really is and how functions in F# differ from those in other languages. Once we’ve estab- lished that foundation, we’ll explore several data types commonly used with functional programming and take a brief side trip into lazy evaluation. The Book of F# © 2014 by Dave Fancher What Is Functional Programming? Functional programming takes a fundamentally different approach toward developing software than object-oriented programming. While object-oriented programming is primarily concerned with managing an ever-changing system state, functional programming emphasizes immutability and the application of deterministic functions. This difference drastically changes the way you build software, because in object-oriented programming you’re mostly concerned with defining classes (or structs), whereas in functional programming your focus is on defining functions with particular emphasis on their input and output. F# is an impure functional language where data is immutable by default, though you can still define mutable data or cause other side effects in your functions.
  • (901133) Instructor: Eng

    (901133) Instructor: Eng

    home Al-Albayt University Computer Science Department C++ Programming 1 (901133) Instructor: Eng. Rami Jaradat [email protected] 1 home Subjects 1. Introduction to C++ Programming 2. Control Structures 3. Functions 4. Arrays 5. Pointers 6. Strings 2 home 1 - Introduction to C++ Programming 3 home What is computer? • Computers are programmable devices capable of performing computations and making logical decisions. • Computers can store, retrieve, and process data according to a list of instructions • Hardware is the physical part of the compute: keyboard, screen, mouse, disks, memory, and processing units • Software is a collection of computer programs, procedures and documentation that perform some tasks on a computer system 4 home Computer Logical Units • Input unit – obtains information (data) from input devices • Output unit – outputs information to output device or to control other devices. • Memory unit – Rapid access, low capacity, stores information • Secondary storage unit – cheap, long-term, high-capacity storage, stores inactive programs • Arithmetic and logic unit (ALU) – performs arithmetic calculations and logic decisions • Central processing unit (CPU): – supervises and coordinates the other sections of the computer 5 home Computer language • Machine languages: machine dependent, it consists of strings of numbers giving machine specific instructions: +1300042774 +1400593419 +1200274027 • Assembly languages: English-like abbreviations representing elementary operations, assemblers convert assembly language to machine
  • Crosscore Embedded Studio 2.2.0 C/C++ Compiler Manual for SHARC

    Crosscore Embedded Studio 2.2.0 C/C++ Compiler Manual for SHARC

    CrossCore Embedded Studio 2.2.0 C/C++ Compiler Manual for SHARC Processors Revision 1.5, February 2016 Part Number 82-100117-01 Analog Devices, Inc. One Technology Way Norwood, MA 02062-9106 Copyright Information ©2016 Analog Devices, Inc., ALL RIGHTS RESERVED. This document may not be reproduced in any form without prior, express written consent from Analog Devices, Inc. Printed in the USA. Disclaimer Analog Devices, Inc. reserves the right to change this product without prior notice. Information furnished by Ana- log Devices is believed to be accurate and reliable. However, no responsibility is assumed by Analog Devices for its use; nor for any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under the patent rights of Analog Devices, Inc. Trademark and Service Mark Notice The Analog Devices logo, Blackfin, CrossCore, EngineerZone, EZ-Board, EZ-KIT, EZ-KIT Lite, EZ-Extender, SHARC, and VisualDSP++ are registered trademarks of Analog Devices, Inc. Blackfin+, SHARC+, and EZ-KIT Mini are trademarks of Analog Devices, Inc. All other brand and product names are trademarks or service marks of their respective owners. CrossCore Embedded Studio 2.2.0 i Contents Preface Purpose of This Manual................................................................................................................................. 1±1 Intended Audience........................................................................................................................................
  • Explicitly Implicifying Explicit Constructors

    Explicitly Implicifying Explicit Constructors

    Explicitly Implicifying explicit Constructors Document number: P1163R0 Date: 2018-08-31 Project: Programming Language C++, Library Working Group Reply-to: Nevin “☺” Liber, [email protected] or [email protected] Table of Contents Revision History ................................................................................................................ 3 P11630R0 .................................................................................................................................... 3 Introduction ....................................................................................................................... 4 Motivation and Scope ....................................................................................................... 5 Impact On the Standard ................................................................................................... 6 Policy .................................................................................................................................. 7 Design Decisions ................................................................................................................ 8 Technical Specifications ................................................................................................... 9 [template.bitset]........................................................................................................................ 10 [bitset.cons] ..............................................................................................................................
  • Run-Time Type Information and Incremental Loading in C++

    Run-Time Type Information and Incremental Loading in C++

    Run-time Type Information and Incremental Loading in C++ Murali Vemulapati Sriram Duvvuru Amar Gupta WP #3772 September 1993 PROFIT #93-11 Productivity From Information Technology "PROFIT" Research Initiative Sloan School of Management Massachusetts Institute of Technology Cambridge, MA 02139 USA (617)253-8584 Fax: (617)258-7579 Copyright Massachusetts Institute of Technology 1993. The research described herein has been supported (in whole or in part) by the Productivity From Information Technology (PROFIT) Research Initiative at MIT. This copy is for the exclusive use of PROFIT sponsor firms. Productivity From Information Technology (PROFIT) The Productivity From Information Technology (PROFIT) Initiative was established on October 23, 1992 by MIT President Charles Vest and Provost Mark Wrighton "to study the use of information technology in both the private and public sectors and to enhance productivity in areas ranging from finance to transportation, and from manufacturing to telecommunications." At the time of its inception, PROFIT took over the Composite Information Systems Laboratory and Handwritten Character Recognition Laboratory. These two laboratories are now involved in research re- lated to context mediation and imaging respectively. LABORATORY FOR ELEC RONICS A CENTERCFORENTER COORDINATION LABORATORY ) INFORMATION S RESEARCH RESE CH E53-310, MITAL"Room Cambridge, MA 02M142-1247 Tel: (617) 253-8584 E-Mail: [email protected] Run-time Type Information and Incremental Loading in C++ September 13, 1993 Abstract We present the design and implementation strategy for an integrated programming environment which facilitates specification, implementation and execution of persistent C++ programs. Our system is implemented in E, a persistent programming language based on C++. The environment provides type identity and type persistence, i.e., each user-defined class has a unique identity and persistence across compilations.
  • MISRA-C:2004 Guidelines for the Use of the C Language in Critical Systems

    MISRA-C:2004 Guidelines for the Use of the C Language in Critical Systems

    MISRA-C:2004 Guidelines for the use of the C language in critical systems October 2004 Licensed to: Tyler Doering. 10 Sep 2008. Copy 1 of 1 First published October 2004 by MIRA Limited Watling Street Nuneaton Warwickshire CV10 0TU UK www.misra-c.com Edition 2 reprinted July 2008 incorporating Technical Corrigendum 1 © MIRA Limited, 2004, 2008. “MISRA”, “MISRA C” and the triangle logo are registered trademarks of MIRA Limited, held on behalf of the MISRA Consortium. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical or photocopying, recording or otherwise without the prior written permission of the Publisher. ISBN 978-0-9524156-2-6 paperback ISBN 978-0-9524156-4-0 PDF Printed by Hobbs the Printers Ltd British Library Cataloguing in Publication Data. A catalogue record for this book is available from the British Library This copy of MISRA-C:2004 - Guidelines for the use of the C language in critical systems is issued to Tyler Doering. The file must not be altered in any way. No permission is given for distribution of this file. This includes but is not exclusively limited to making the copy available to others by email, placing it on a server for access by intra- or inter-net, or by printing and distributing hardcopies. Any such use constitutes an infringement of copyright. MISRA gives no guarantees about the accuracy of the information contained in this PDF version of the Guidelines. The published paper document should be taken as authoritative.
  • Evaluation of Open Source Operating Systems for Safety-Critical Applications Master’S Thesis in Embedded Electronic System Design

    Evaluation of Open Source Operating Systems for Safety-Critical Applications Master’S Thesis in Embedded Electronic System Design

    Evaluation of open source operating systems for safety-critical applications Master’s thesis in Embedded Electronic System Design Petter Sainio Berntsson Department of Computer Science and Engineering CHALMERS UNIVERSITY OF TECHNOLOGY UNIVERSITY OF GOTHENBURG Gothenburg, Sweden 2017 MASTER’S THESIS 2017 Evaluation of open source operating systems for Safety-critical applications Petter Sainio Berntsson Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2017 Evaluation of open source operating systems for safety-critical applications Petter Sainio Berntsson © Petter Sainio Berntsson, 2017 Examiner: Per Larsson-Edefors Chalmers University of Technology Department of Computer Science and Engineering Academic supervisor: Jan Jonsson Chalmers University of Technology Department of Computer Science and Engineering Industrial supervisors: Lars Strandén RISE Research Institutes of Sweden Dependable Systems Fredrik Warg RISE Research Institutes of Sweden Dependable Systems Master’s Thesis 2017 Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg SE-412 96 Gothenburg Telephone +46(0) 31 772 1000 Abstract Today many embedded applications will have to handle multitasking with real-time time constraints and the solution for handling multitasking is to use a real-time operating system for scheduling and managing the real-time tasks. There are many different open source real-time operating systems available and the use of open source software for safety-critical applications is considered highly interesting by industries such as medical, aerospace and automotive as it enables a shorter time to market and lower development costs. If one would like to use open source software in a safety-critical context one would have to provide evidence that the software being used fulfills the requirement put forth by the industry specific standard for functional safety, such as the ISO 26262 standard for the automotive industry.