DOCSLIB.ORG

Finding Strategies for Executing Ada-Code in Real-Time on Linux Using an Embedded Computer

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Finding Strategies for Executing Ada-Code in Real-Time on Linux Using an Embedded Computer Finding strategies for executing Ada-code in real-time on Linux using an embedded computer. ADAM LUNDSTRÖM Master’s Degree Project Stockholm, Sweden March 2016 MMK 2016:12 MDA 524 Abstract A combination of Ada, real-time Linux and an embedded computer is a cost- eective solution that accommodates most of the demands of embedded systems development or prototyping. Linux in its standard conguration is not suitable for real-time applications, but there exists solutions that modies it to be more real-time capable. The question is, what modication is the optimal one from an Ada perspective? To answer this, a literature study has been conducted to identify solutions, followed by an analysis that gures out the most promising one. The selected solution has then been further evaluated and veried by bench- marks and tests running on a BeagleBone Black. The evaluation results shows that the PREEMPT_RT real-time patches for Linux is the optimal solution for enabling real-time execution of Ada code. Two other promising solutions were Xenomai and RTAI, they provide better performance in terms of lower latencies but does not have full Ada support and requires code to be specically targeted to their solutions compared to PREEMPT_RT that is transparent to the user. The worst case latencies for PREEMPT_RT were measured with Cyclictest while the system was stressed by using Sysbench, Hackbench and ping ooding. The tests stressed dierent part of the system, e.g CPU, memory and le IO, making it possible to determine how sensitive the latencies are to dierent types of applica- tions. Two of the tests stood out from the others, the ping ood and the Sysbench Thread-test. When pinging the system the worst case latencies were 364 µs, in the order of three times higher than the other loads. The other deviating result was observed when the system was loaded using the Sysbench Thread-test, the latencies were actually lower compared to the unloaded system, 62 µs versus 90 µs. The reason for this is dicult to determine due to the size and complexity of Linux, it would require a deeper analysis of the kernel code. PREEMPT_RT allows existing applications for Linux to run without modica- tion to the source code which makes it attractive for developing mixed type sys- tems that require real-time predictability, general purpose exibility and high throughput. It is a cost-eective solution that could be used for teaching Ada and making prototypes that don’t require the highest levels of safety certica- tion. The latencies are not low enough to accommodate the demands of all sys- tems, but many systems require latencies only to be in the order of milliseconds, which this solution would be suitable for. Sammanfattning En kombination av Ada, realtids-Linux och en enkortsdator är en kostnadseek- tiv lösning som möter de esta av behoven för utveckling och prototypframtag- ning inom inbyggda system. Linux är i sin standardkonguration inte lämplig för realtidsapplikationer, men det nns lösningar som gör Linux mer realtids an- passat. Frågan är, vilken lösning är den optimala från ett Ada perspektiv? För att svara på detta har en litteraturstudie utförts för att identiera olika lösningar, följt av en analys som tar fram den mest lovande. Den utvalda lösningen har se- dan utvärderats och verierats genom tester som körts på en BeagleBone Black. Utvärderingen visar att lösningen PREEMPT_RT för Linux är den optimala för realtids-exekvering av kod skriven i Ada. Två andra lovande lösningar är Xe- nomai och RTAI, de uppvisar bättre prestanda genom kortare fördröjningar. Men de har inte fullt stöd för Ada och kräver att kod anpassas för deras lösning till skillnad från PREEMPT_RT som är transparent för användaren. Fördröjningarna för PREEMP_RT mättes upp med Cyclictest samtidigt som sy- stemet belastades av Sysbench, Hackbench och ’ping ooding’. Testerna belas- tade olika delar av systemet, till exempel CPUn, minnet och l-IO, vilket gör det möjligt att bestämma hur känsligt systemet är för olika typer av applikationer. Två test särskilde sig från de andra, ’ping ooding’ och Sysbench Thread-test. När systemet pingades mättes fördröjningarna upp till 364 µs, i storleksordning- en tre gånger högre jämfört med de andra testerna. Det andra utmärkande testet var när Sysbench Thread-testet kördes, fördröjningarna var oväntat nog mindre jämfört med det obelastade systemet, 62 µs respektive 90 µs. Anledningen till det är svårt att avgöra på grund av storleken och komplexiteten av Linux, det skulle kräva en djupare analys av Linux-kärnan. PREEMPT_RT tillåter att bentliga applikation för Linux att köras utan föränd- ringar av källkoden vilket gör lösning attraktiv för utveckling av system som kräver realtidsegenskaper, exibilitet och hög prestanda. Det är en kostnadsef- fektiv lösning som kan användas för utbilding i Ada och utveckling av prototyper som inte kräver högsta nivån av säkerhetscertiering. Fördröjningarna är inte tillräckligt låga för att kunna möta kraven för alla system, men ofta är kraven i storleksordningen av millisekunder, vilket den här lösningen skulle vara lämplig för. Acknowledgements I would like to thank my supervisors Xinhai Zhang and Sagar Behere for their guidance. Contents 1 Introduction3 1.1 Motivation - Complex Systems...................3 1.1.1 Advantages of Ada.....................5 1.1.2 Advantages of Linux....................6 1.1.3 Combined Eect......................7 1.2 Implementation Challenges.....................7 1.3 Contributions............................8 1.4 Outline................................8 2 Background9 2.1 Programming Languages......................9 2.1.1 Ada.............................9 2.1.1.1 Example Code.................. 10 2.1.2 Ada Case Studies...................... 11 2.1.3 Factors for Choosing a Language............. 12 2.1.4 Popular Languages: Surveys................ 15 2.1.5 Why is Ada not More Used?................ 16 2.1.6 Summary.......................... 20 2.2 Computational Hardware - Challenges.............. 21 2.3 Real-Time.............................. 26 2.3.1 What is Real-Time?..................... 26 2.3.2 Real-Time Implementation Challenges.......... 28 2.4 Operating Systems.......................... 29 3 Research Design 31 3.1 Research Goals............................ 31 3.2 Research question.......................... 31 3.3 Methodology............................. 31 3.3.1 Reliability.......................... 32 3.3.2 Validity........................... 33 4 Literature Study 35 4.1 Real-time Linux Modications................... 35 4.1.1 Step 1. Background..................... 36 4.1.2 Step 2. Finding solutions.................. 36 4.1.3 Step 3. Rened Study.................... 38 4.1.4 Step 4. Focused Study................... 39 4.2 Programming languages...................... 40 1 5 Exploring Solutions 41 5.1 Mainline Linux............................ 41 5.2 Real-Time Linux........................... 42 5.3 Ada Compatibility.......................... 43 5.4 Candidates.............................. 44 5.4.1 Hard Real-Time....................... 47 5.5 Summary............................... 48 6 Verication and Evaluation 50 6.1 Compiling the Kernel........................ 51 6.2 Verifying the Compiler....................... 52 6.3 Benchmarking............................ 53 6.3.1 Benchmarking Setup.................... 54 6.4 Results and Discussion....................... 55 7 Conclusions 59 References 61 Appendices 78 A Setting up the System 79 B Scripts for Testing 80 C Programming Languages 86 D Evidence in Computer Science 97 2 1 Introduction 1.1 Motivation - Complex Systems Self-driving vehicles are lurking in the horizon, robots are moving into our homes and the fusion of sensors can be used for analyzing our mental and physical state. These types of systems can be called embedded, cyber-physical, real-time (see section 2.3), safety-critical and ’Internet of things’. For people familiar with these systems the dierences between them might be clear, for others it’s dier- ent names for the same thing. This thesis is concerned with all these systems and will not divulge into denitions, merely the viewpoint here is that usually these systems are some sort of embedded systems, sometimes connected in a networked fashion, sometimes isolated from other systems and sometimes con- nected to the Internet. With more than 98% of all the microprocessors being embedded [1] it’s a signicant area for research. These systems are becoming more complex. Since cars are a seemingly universal way to explain things examples will be provided from that domain. As [2] ex- plains, the car has evolved through systems of isolated functions to cooperative systems where the functions are connected in networked form. They mention how one of the rst systems, like anti-lock breaking, was an isolated function only concerned with its own task, but now there are more advanced systems, for example active break assistance (ABA) that makes connections between several functions like breaking, steering and input/output from the dashboard. There is a trend towards developing self-driving vehicles, a challenge is how to make them safe. One way to solve the safety issues can be by having a person be- hind the wheel, ready to intervene in case of computer failure. But if cars evolves in the same way as aircrafts do, being impossible to operate without computer control [3], the computer system must control the vehicle in all situations with- out relying on a human to intervene if it fails. This full autonomy puts enormous pressure on the software
Load more

Recommended publications
  • Industrial Control Via Application Containers: Migrating from Bare-Metal to IAAS
    Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS Florian Hofer, Student Member, IEEE Martin A. Sehr Antonio Iannopollo, Member, IEEE Faculty of Computer Science Corporate Technology EECS Department Free University of Bolzano-Bozen Siemens Corporation University of California Bolzano, Italy Berkeley, CA 94704, USA Berkeley, CA 94720, USA fl[email protected] [email protected] [email protected] Ines Ugalde Alberto Sangiovanni-Vincentelli, Fellow, IEEE Barbara Russo Corporate Technology EECS Department Faculty of Computer Science Siemens Corporation University of California Free University of Bolzano-Bozen Berkeley, CA 94704, USA Berkeley, CA 94720, USA Bolzano, Italy [email protected] [email protected] [email protected] Abstract—We explore the challenges and opportunities of control design full authority over the environment in which shifting industrial control software from dedicated hardware to its software will run, it is not straightforward to determine bare-metal servers or cloud computing platforms using off the under what conditions the software can be executed on cloud shelf technologies. In particular, we demonstrate that executing time-critical applications on cloud platforms is viable based on computing platforms due to resource virtualization. Yet, we a series of dedicated latency tests targeting relevant real-time believe that the principles of Industry 4.0 present a unique configurations. opportunity to explore complementing traditional automation Index Terms—Industrial Control Systems, Real-Time, IAAS, components with a novel control architecture [3]. Containers, Determinism We believe that modern virtualization techniques such as application containerization [3]–[5] are essential for adequate I. INTRODUCTION utilization of cloud computing resources in industrial con- Emerging technologies such as the Internet of Things and trol systems.
    [Show full text]
  • Nintendo Wii Software
    Nintendo wii software A previous update, ( U) introduced the ability to transfer your data from one Wii U console to another. You can transfer save data for Wii U software, Mii. The Wii U video game console's built-in software lets you watch movies and have fun right out of the box. BTW, why does it sound like you guys are crying about me installing homebrew software on my Wii console? I am just wondering because it seems a few of you. The Nintendo Wii was introduced in and, since then, over pay for any of this software, which is provided free of charge to everyone. Perform to Popular Chart-Topping Tunes - Sing up to 30 top hits from Season 1; Gleek Out to Never-Before-Seen Clips from the Show – Perform to video. a wiki dedicated to homebrew on the Nintendo Wii. We have 1, articles. Install the Homebrew Channel on your Wii console by following the homebrew setup tutorial. Browse the Homebrew, Wii hardware, Wii software, Development. The Wii was not designed by Nintendo to support homebrew. There is no guarantee that using homebrew software will not harm your Wii. A crazy software issue has come up. It's been around 10 months since the wii u was turned on at all. Now that we have, it boots up fine and you. Thus, we developed a balance assessment software using the Nintendo Wii Balance Board, investigated its reliability and validity, and. In Q1, Nintendo DS software sales were million, up million units Wii software sales reached million units, a million.
    [Show full text]
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • Design Languages for Embedded Systems
    Design Languages for Embedded Systems Stephen A. Edwards Columbia University, New York [email protected] May, 2003 Abstract ward hardware simulation. VHDL’s primitive are assign- ments such as a = b + c or procedural code. Verilog adds Embedded systems are application-specific computers that transistor and logic gate primitives, and allows new ones to interact with the physical world. Each has a diverse set be defined with truth tables. of tasks to perform, and although a very flexible language might be able to handle all of them, instead a variety of Both languages allow concurrent processes to be de- problem-domain-specific languages have evolved that are scribed procedurally. Such processes sleep until awak- easier to write, analyze, and compile. ened by an event that causes them to run, read and write variables, and suspend. Processes may wait for a pe- This paper surveys some of the more important lan- riod of time (e.g., #10 in Verilog, wait for 10ns in guages, introducing their central ideas quickly without go- VHDL), a value change (@(a or b), wait on a,b), ing into detail. A small example of each is included. or an event (@(posedge clk), wait on clk un- 1 Introduction til clk='1'). An embedded system is a computer masquerading as a non- VHDL communication is more disciplined and flexible. computer that must perform a small set of tasks cheaply and Verilog communicates through wires or regs: shared mem- efficiently. A typical system might have communication, ory locations that can cause race conditions. VHDL’s sig- signal processing, and user interface tasks to perform.
    [Show full text]
  • Riscv-Software-Stack-Tutorial-Hpca2015
    Software Tools Bootcamp RISC-V ISA Tutorial — HPCA-21 08 February 2015 Albert Ou UC Berkeley [email protected] Preliminaries To follow along, download these slides at http://riscv.org/tutorial-hpca2015.html 2 Preliminaries . Shell commands are prefixed by a “$” prompt. Due to time constraints, we will not be building everything from source in real-time. - Binaries have been prepared for you in the VM image. - Detailed build steps are documented here for completeness but are not necessary if using the VM. Interactive portions of this tutorial are denoted with: $ echo 'Hello world' . Also as a reminder, these slides are marked with an icon in the upper-right corner: 3 Software Stack . Many possible combinations (and growing) . But here we will focus on the most common workflows for RISC-V software development 4 Agenda 1. riscv-tools infrastructure 2. First Steps 3. Spike + Proxy Kernel 4. QEMU + Linux 5. Advanced Cross-Compiling 6. Yocto/OpenEmbedded 5 riscv-tools — Overview “Meta-repository” with Git submodules for every stable component of the RISC-V software toolchain Submodule Contents riscv-fesvr RISC-V Frontend Server riscv-isa-sim Functional ISA simulator (“Spike”) riscv-qemu Higher-performance ISA simulator riscv-gnu-toolchain binutils, gcc, newlib, glibc, Linux UAPI headers riscv-llvm LLVM, riscv-clang submodule riscv-pk RISC-V Proxy Kernel (riscv-linux) Linux/RISC-V kernel port riscv-tests ISA assembly tests, benchmark suite All listed submodules are hosted under the riscv GitHub organization: https://github.com/riscv 6 riscv-tools — Installation . Build riscv-gnu-toolchain (riscv*-*-elf / newlib target), riscv-fesvr, riscv-isa-sim, and riscv-pk: (pre-installed in VM) $ git clone https://github.com/riscv/riscv-tools $ cd riscv-tools $ git submodule update --init --recursive $ export RISCV=<installation path> $ export PATH=${PATH}:${RISCV}/bin $ ./build.sh .
    [Show full text]
  • RTAI-Lab Tutorial: Scicoslab, Comedi, and Real-Time Control
    RTAI-Lab tutorial: Scicoslab, Comedi, and real-time control Roberto Bucher 1 Simone Mannori Thomas Netter 2 May 24, 2010 Summary RTAI-Lab is a tool chain for real-time software and control system development. This tutorial shows how to install the various components: the RTAI real-time Linux kernel, the Comedi interface for control and measurement hardware, the Scicoslab GUI-based CACSD modeling software and associated RTAI-Lab blocks, and the xrtailab interactive oscilloscope. RTAI-Lab’s Scicos blocks are detailed and examples show how to develop elementary block diagrams, automatically generate real-time executables, and add custom elements. 1Main RTAI-Lab developer, person to contact for technical questions: roberto.bucher at supsi.ch, see page 46 Contents 1 Introduction 4 1.1 RTAI-Lab tool chain . .4 1.2 Commercial software . .4 2 Installation 5 2.1 Requirements . .5 2.1.1 Hardware requirements . .5 2.1.2 Software requirements . .6 2.2 Mesa library . .7 2.3 EFLTK library . .7 2.4 Linux kernel and RTAI patch . .7 2.5 Comedilib . .8 2.6 RTAI (1st pass) . .8 2.7 RTAI tests . .9 2.8 Comedi . .9 2.9 RTAI (2nd pass) . 10 2.10 ScicosLab . 11 2.11 RTAI-Lab add-ons to Scicoslab-4.4 . 11 2.12 User configuration for scicoslab-4.4 . 11 2.13 Load the modules . 11 3 Development with RTAI-Lab 13 3.1 Boot Linux-RTAI . 13 3.2 Start Scicos . 13 3.3 RTAI-Lib palette . 14 3.4 Real-time sinewave: step by step . 16 3.4.1 Create block diagram .
    [Show full text]
  • Operating Systems and Applications for Embedded Systems >>> Toolchains
    >>> Operating Systems And Applications For Embedded Systems >>> Toolchains Name: Mariusz Naumowicz Date: 31 sierpnia 2018 [~]$ _ [1/19] >>> Plan 1. Toolchain Toolchain Main component of GNU toolchain C library Finding a toolchain 2. crosstool-NG crosstool-NG Installing Anatomy of a toolchain Information about cross-compiler Configruation Most interesting features Sysroot Other tools POSIX functions AP [~]$ _ [2/19] >>> Toolchain A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes a compiler, a linker, and run-time libraries. [1. Toolchain]$ _ [3/19] >>> Main component of GNU toolchain * Binutils: A set of binary utilities including the assembler, and the linker, ld. It is available at http://www.gnu.org/software/binutils/. * GNU Compiler Collection (GCC): These are the compilers for C and other languages which, depending on the version of GCC, include C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. They all use a common back-end which produces assembler code which is fed to the GNU assembler. It is available at http://gcc.gnu.org/. * C library: A standardized API based on the POSIX specification which is the principle interface to the operating system kernel from applications. There are several C libraries to consider, see the following section. [1. Toolchain]$ _ [4/19] >>> C library * glibc: Available at http://www.gnu.org/software/libc. It is the standard GNU C library. It is big and, until recently, not very configurable, but it is the most complete implementation of the POSIX API. * eglibc: Available at http://www.eglibc.org/home.
    [Show full text]
  • Linux Journal | February 2016 | Issue
    ™ A LOOK AT KDE’s KStars Astronomy Program Since 1994: The Original Magazine of the Linux Community FEBRUARY 2016 | ISSUE 262 | www.linuxjournal.com + Programming Working with Command How-Tos Arguments in Your Program a Shell Scripts BeagleBone Interview: Katerina Black Barone-Adesi on to Help Brew Beer Developing the Snabb Switch Network Write a Toolkit Short Script to Solve a WATCH: ISSUE Math Puzzle OVERVIEW V LJ262-February2016.indd 1 1/21/16 5:26 PM NEW! Agile Improve Product Business Development Processes with an Enterprise Practical books Author: Ted Schmidt Job Scheduler for the most technical Sponsor: IBM Author: Mike Diehl Sponsor: people on the planet. Skybot Finding Your DIY Way: Mapping Commerce Site Your Network Author: to Improve Reuven M. Lerner Manageability GEEK GUIDES Sponsor: GeoTrust Author: Bill Childers Sponsor: InterMapper Combating Get in the Infrastructure Fast Lane Sprawl with NVMe Author: Author: Bill Childers Mike Diehl Sponsor: Sponsor: Puppet Labs Silicon Mechanics & Intel Download books for free with a Take Control Linux in simple one-time registration. of Growing the Time Redis NoSQL of Malware http://geekguide.linuxjournal.com Server Clusters Author: Author: Federico Kereki Reuven M. Lerner Sponsor: Sponsor: IBM Bit9 + Carbon Black LJ262-February2016.indd 2 1/21/16 5:26 PM NEW! Agile Improve Product Business Development Processes with an Enterprise Practical books Author: Ted Schmidt Job Scheduler for the most technical Sponsor: IBM Author: Mike Diehl Sponsor: people on the planet. Skybot Finding Your DIY Way: Mapping Commerce Site Your Network Author: to Improve Reuven M. Lerner Manageability GEEK GUIDES Sponsor: GeoTrust Author: Bill Childers Sponsor: InterMapper Combating Get in the Infrastructure Fast Lane Sprawl with NVMe Author: Author: Bill Childers Mike Diehl Sponsor: Sponsor: Puppet Labs Silicon Mechanics & Intel Download books for free with a Take Control Linux in simple one-time registration.
    [Show full text]
  • Compiler Construction
    Compiler Construction Chapter 11 Compiler Construction Compiler Construction 1 A New Compiler • Perhaps a new source language • Perhaps a new target for an existing compiler • Perhaps both Compiler Construction Compiler Construction 2 Source Language • Larger, more complex languages generally require larger, more complex compilers • Is the source language expected to evolve? – E.g., Java 1.0 ! Java 1.1 ! . – A brand new language may undergo considerable change early on – A small working prototype may be in order – Compiler writers must anticipate some amount of change and their design must therefore be flexible – Lexer and parser generators (like Lex and Yacc) are therefore better than hand- coding the lexer and parser when change is inevitable Compiler Construction Compiler Construction 3 Target Language • The nature of the target language and run-time environment influence compiler construction considerably • A new processor and/or its assembler may be buggy Buggy targets make it difficult to debug compilers for that target! • A successful source language will persist over several target generations – E.g., 386 ! 486 ! Pentium ! . – Thus the design of the IR is important – Modularization of machine-specific details is also important Compiler Construction Compiler Construction 4 Compiler Performance Issues • Compiler speed • Generated code quality • Error diagnostics • Portability • Maintainability Compiler Construction Compiler Construction 5 Compiler Speed • Reduce the number of modules • Reduce the number of passes Perhaps generate machine
    [Show full text]
  • Sr. Firmware - Embedded Software Engineer
    SR. FIRMWARE - EMBEDDED SOFTWARE ENGINEER Atel USA is a leading provider of high-performance, small form-factor tracking systems for the vehicle recovery, fleet, heavy trucks, and asset tracking industries. Our team has years of experience in developing complex wireless and communications systems. We have shipped several millions of vehicle tracking devices operating on all major cellular networks. We are seeking an enthusiastic embedded software engineer to be a key team member in the design, implementation, and verification of our asset tracking devices and sensory accessories. The Sr. Firmware Engineer will become an integral part of our company and will work as part of a small, multi-disciplinary development team to design, construct and deliver software/firmware for our current and next generation products. Primary Responsibilities: • Work independently on project tasks as well as work as a team member of a larger project team. • Collaborate with hardware/system design engineers to define the product feature set and work within a product development team to deliver firmware that meets or exceeds product requirements. • Engage with customers and product managers to define requirements, develop software architecture, and plan development in dynamic, evolving customer driven environment. • Deliver innovative solutions from concept to prototype to production. • Conduct/participate in engineering reviews to provide technical input on product designs and quality. • Conduct software unit tests to exercise implemented functionality. • Document software designs. • Troubleshoot and remove defects from production software. • Communicate and interact with team and customers to clearly set expectations, share technical details, resolve issues, and report progress. • Participate in brainstorms and otherwise contribute outside your area of expertise.
    [Show full text]
  • A Model-Driven Development and Verification Approach
    A MODEL-DRIVEN DEVELOPMENT AND VERIFICATION APPROACH FOR MEDICAL DEVICES by Jakub Jedryszek B.S., Wroclaw University of Technology, Poland, 2012 B.A., Wroclaw University of Economics, Poland, 2012 A THESIS submitted in partial fulfillment of the requirements for the degree MASTER OF SCIENCE Department of Computing and Information Sciences College of Engineering KANSAS STATE UNIVERSITY Manhattan, Kansas 2014 Approved by: Major Professor John Hatcliff Abstract Medical devices are safety-critical systems whose failure may put human life in danger. They are becoming more advanced and thus more complex. This leads to bigger and more complicated code-bases that are hard to maintain and verify. Model-driven development provides high-level and abstract description of the system in the form of models that omit details, which are not relevant during the design phase. This allows for certain types of verification and hazard analysis to be performed on the models. These models can then be translated into code. However, errors that do not exist in the models may be introduced during the implementation phase. Automated translation from verified models to code may prevent to some extent. This thesis proposes approach for model-driven development and verification of medi- cal devices. Models are created in AADL (Architecture Analysis & Design Language), a language for software and hardware architecture modeling. AADL models are translated to SPARK Ada, contract-based programming language, which is suitable for software veri- fication. Generated code base is further extended by developers to implement internals of specific devices. Created programs can be verified using SPARK tools. A PCA (Patient Controlled Analgesia) pump medical device is used to illustrate the primary artifacts and process steps.
    [Show full text]
  • Linux Everywhere a Look at Linux Outside the World of Desktops
    Linux Everywhere A look at Linux outside the world of desktops CIS 191 Spring 2012 – Guest Lecture by Philip Peng Lecture Outline 1. Introduction 2. Different Platforms 3. Reasons for Linux 4. Cross-compiling 5. Case Study: iPodLinux 6. Questions 2 What’s in common? 3 All your hardware are belong to us • Linux is everywhere – If its programmable, you can put Linux on it! – Yes, even a microwave CES 2010, microwave running Android: http://www.handlewithlinux.com/linux-washing-cooking 4 Servers • What servers use – Stability, security, free – Examples: ◦ CentOS ◦ Debian ◦ Red Hat 5 Desktop • What you use – Free Windows/Mac alternative – Examples: ◦ Ubuntu ◦ Fedora ◦ PCLinuxOS 6 Gaming Devices • What (white-hat) hackers do – To run “homebrew” software – Examples: ◦ PS3, Wii, XBOX ◦ PS2, GameCube ◦ Dreamcast ◦ PSP, DS ◦ Open Pandora, GP2X 7 Mobile Devices • What distributors are developing – Community contribution – Examples ◦ Android ◦ Maemo/MeeGo/Tizen ◦ Openmoko 8 Embedded Devices • What embedded hardware run – Small footprint, dev tools – Examples ◦ RTLinux (real-time) ◦ μClinux (no MMU) ◦ Ångström (everything) 9 Why? 10 Free! • Free! – As in freedom, i.e. open source – As in beer, i.e. vs paid upgrades 11 Homebrew! • Run own software – Your hardware your software? 12 Support! • Community contribution – “For the greater good” (i.e. users) – Everyone contributes ◦ Specialists from all over the world – Existing hardware support ◦ Many already supported computer architecture ◦ Modify existing drivers 13 Lots of support! 14 Why not? • Because we can – If its hackable, it can run Linux 15 How? • How do we get Linux running on XXX? • Port: A version of software modified to run on a different target platform – The PS3 port of Fedora is a modified build of Fedora compiled to run on the PS3 architecture – e.g.
    [Show full text]