Gnu linux for safety related systems

2,930 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,930
On SlideShare
0
From Embeds
0
Number of Embeds
146
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Gnu linux for safety related systems

  1. 1. Technical breakfastGNU/Linux for Safety Related Systems
  2. 2. Introduction• Embedded World – March 2011 – Nicholas McGuire (OSADL)• GNU/Linux for Safety Related SystemsSafety related systems Systems needed to guarantee the safety of their users and the environment• Find out if GNU/Linux is a suitable platform for safety-critical applications
  3. 3. Introduction: Contents1. Linux and GNU/Linux • Software development • Kernel management: the git way • Modularity of Linux and GNU/Linux distributions2. Tools for kernel development and its management • git • make C=1 • cscope • coccinelle (spatch) • sparse • gcov && gprof3. Safety • Safety and IEC 61508
  4. 4. 1.- Linux and GNU/Linux• Linux is the kernel of the GNU/Linux operating system.• It must guarantee a high quality of service (QoS).• Many important attributes are (RAMS): Operating System • Reliability (e.g., GNU/Linux) • Availability Applications • Maintainability • Safety Kernel (e.g., Linux) HW• The kernel manages access to the hardware and forms a layer between the hardware and the so-called user space programs.• An operating system is more than a kernel. e.g. it offers compilers, editors, ftp/web servers, ...
  5. 5. 1.- Software development: The Traditional Way • Build and Fix Cycle • Software Life-Cycle Model • The Waterfall Model • The V-Model • The Spiral Model • The Incremental Model • Extreme Programming
  6. 6. 1.- Kernel development: The Open Source way • Open Source Development Model Community Review DevelopCommunication via email on mailing-lists Commit
  7. 7. 1.- Kernel development: The Open Source way• Open Source Development Model: Some tools... sum.orig.c int sum (int a, int b) { return (a - b); }
  8. 8. 1.- Kernel development: The Open Source way• Open Source Development Model: Some tools... sum.c int sum (int a, int b) { return (a + b); }
  9. 9. 1.- Kernel development: The Open Source way• Open Source Development Model: Some tools... diff Outputs changes to source code in a readable way sum_diff_file --- sum.orig.c 2008-02-06 16:30:16.000000000 +01.00 +++ sum.c 2008-02-06 16:30:36.000000000 +01.00 @@ -1,4 +1,4 @@ int sum(int a, int b) { - return (a-b); + return (a+b); }
  10. 10. 1.- Kernel development: The Open Source way• Open Source Development Model: Some tools... patch It is used to apply a diff to the original file sum_diff_file --- sum.orig.c 2008-02-06 16:30:16.000000000 +01.00 +++ sum.c 2008-02-06 16:30:36.000000000 +01.00 @@ -1,4 +1,4 @@ int sum(int a, int b) { - return (a-b); + return (a+b); }
  11. 11. 1.- Kernel development: The Open Source way• “The code will become ruined if everyone can submit code”  FALSE • Different layers of authority • Tag “signed-off by” Linus Torvalds && Andrew 2 Morton (Kernel v2.6) Subarchitecture maintainer (USB, networking, …) 300 File maintainer (group) Userbase 1000
  12. 12. 1.- Kernel management: The git way git Is a source configuration management (SCM) tool as SVN, CVS, …• Typical git cycle: • Programmer clones Linus’ repository • Programmer makes a local branch • Programmer edit files • Programmer sends diff files to the mailing list • Programmer commits files to his or her repository • Linus incorporates the changes into the official tree• It guarantees source code integrity. SHA1 algorithm in each commit to generate checksum based in: • The content of a object • The “parent” commits of an object • The comment message for the object• Use a long-term stable version of the kernel
  13. 13. 1.- The Modularity of Linux and GNU/Linuxdistributions• Modularity(GNU/Linux) vs No-modularity (Windows, MAC, ...)• 1st level: kernel  Disable unused features before compiling. They are not disabled at runtime, they do not exist in the binary image. File systems, networking features, ...• 2nd level: application  Compile the applications with exactly the necessary features. Apache example• 3rd level: choice of applications  Some other operating systems do not have this capability. Command line shell and GUI examples
  14. 14. 1.- Testing• Safety standards require some degree of formal verification and testing which is necessary to guarantee safety• Industry has reacted to this important problem, and several organizations and projects has been created: • Linux Test Project (LTP) • Linux Foundation • Linux Kernel Performance • AutoTest • OSADL
  15. 15. 1.- Kernel Stable tree• Kernel Stable-tree (2.6.x.y)• It is for updates on the safety and security of the system.• New features always have the potential of introducing new bugs.• Concentrating on fixing bugs without introducing new features is the best way to keep the system current and stable.• Some distributions provide backports to their stable line of distribution: v1.2.3_1,...
  16. 16. 2.- Tools for kernel development (I) DEMO• git: source configuration management tool• cscope: developer’s tool for browsing source code• sparse: reports semantic errors and it is used when we compile with “make C=1” – address space mismatch – type mismatches – bad casting – lock context: semaphores, flags, locks, ... – portability warning – man sparse for (a lot) more
  17. 17. 2.- Tools for kernel development (II) DEMO• make C = 1• make V = 1• coccinelle: semantic patching – Differences in spacing, indentation and comments – Choice of names given to variables (use of metavariables) – Irrelevant code (use of ‘...’ operator) – Other variations in coding style (use of isomorphisms) • E.g. if(!y)  if (y==NULL)  if(NULL==y)
  18. 18. 2.- Tools for kernel development (III) DEMO• gcov: test coverage program – To help create more efficient and faster running code – To discover untested parts of a program• gprof: profiling tool to analyze the code’s performance. Find out some basic performance statistics, such as: – How often each line of code executes – What lines of code are actually executed – How much computing time each section of code uses
  19. 19. 3.- Safety Safety definitions: • “Safety is reliability regarding critical failure modes” • “Absence of catastrophic consequences on the user(s) and the environment” • A system or application can only be termed safety-critical if it controls a process that can potentially harm its environment or users • Certification and safety-standards are used. • Standards describe how software should be tested: if it is enough to black- box test the software, of if additional white-box tests are required.
  20. 20. 3.- Safety: IEC 61508 • European standards (IEC 61508, e.g.) allow individual components of the safety-critical system to be certified. • There are four safety integrity levels (SIL). • SIL provides information about the criticality of a system. • Each level requires different development and verification methods. Severity of Failure IEC 61508 Catastrophic SIL 4 Severe SIL 3 Major SIL 2 Minor SIL 1
  21. 21. 3.- Safety: EN 50128 Mandatory Requirements forSIL4 Applications• Modular approach: Decomposition of a software system into small parts in order to limit the complexity of the system.• Design and Coding Standards: A document can be found in the kernel tree that describes the preferred coding style.• Functional testing: Tools for black-box testing and for code coverage analysis.• Performance testing: autotest project and kernel-perf project.• Data recording and analysis: all kernel data are recorded on the kernel homepage.
  22. 22. 3.- Safety: EN 50128 Mandatory Requirements forSIL4 Applications• Compliant with EN ISO 9000-3 and Company Quality System: it depends on the specific safety-critical system and the specific company and its quality system.• SW Configuration Management: – The whole life-cycle of a component is recorded in its git history – It is easy to compare two different versions of a source code file – The commit log files provide information on which changes occurred during the component’s life-cycle• Impact Analysis: to identify the effect that a change or an enhancement to a software system will have to other modules in that software system.
  23. 23. That’s all folks! Thank you!!! Questions, comments, … ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? References - Class: GNU/Linux for safety related systems (Embedded World 2011) - Book: Linux in Safety-Critical Applications (OSADL Academic Works) Roland Kammerer (ISBN: 978-3-00-033885-4)
  24. 24. Technical breakfastGNU/Linux for Safety Related Systems

×