Embedded Systems, Cyber-Physical Systems, and Applications [1 ed.] 9781683921899, 9781601324559

Citation preview

PROCEEDINGS OF THE 2017 INTERNATIONAL CONFERENCE ON EMBEDDED SYSTEMS, CYBER-PHYSICAL SYSTEMS, & APPLICATIONS

Editors Hamid R. Arabnia Leonidas Deligiannidis Fernando G. Tinetti

CSCE’17 July 17-20, 2017 Las Vegas Nevada, USA americancse.org ©

CSREA Press

This volume contains papers presented at The 2017 International Conference on Embedded Systems, Cyber-physical Systems, & Applications (ESCS'17). Their inclusion in this publication does not necessarily constitute endorsements by editors or by the publisher.

Copyright and Reprint Permission Copying without a fee is permitted provided that the copies are not made or distributed for direct commercial advantage, and credit to source is given. Abstracting is permitted with credit to the source. Please contact the publisher for other copying, reprint, or republication permission.

© Copyright 2017 CSREA Press ISBN: 1-60132-455-3 Printed in the United States of America

Foreword It gives us great pleasure to introduce this collection of papers to be presented at the 2017 International Conference on Embedded Systems, Cyber-physical Systems, and Applications (ESCS’17), July 17-20, 2017, at Monte Carlo Resort, Las Vegas, USA. An important mission of the World Congress in Computer Science, Computer Engineering, and Applied Computing, CSCE (a federated congress to which this conference is affiliated with) includes "Providing a unique platform for a diverse community of constituents composed of scholars, researchers, developers, educators, and practitioners. The Congress makes concerted effort to reach out to participants affiliated with diverse entities (such as: universities, institutions, corporations, government agencies, and research centers/labs) from all over the world. The congress also attempts to connect participants from institutions that have teaching as their main mission with those who are affiliated with institutions that have research as their main mission. The congress uses a quota system to achieve its institution and geography diversity objectives." By any definition of diversity, this congress is among the most diverse scientific meeting in USA. We are proud to report that this federated congress has authors and participants from 64 different nations representing variety of personal and scientific experiences that arise from differences in culture and values. As can be seen (see below), the program committee of this conference as well as the program committee of all other tracks of the federated congress are as diverse as its authors and participants. The program committee would like to thank all those who submitted papers for consideration. About 65% of the submissions were from outside the United States. Each submitted paper was peer-reviewed by two experts in the field for originality, significance, clarity, impact, and soundness. In cases of contradictory recommendations, a member of the conference program committee was charged to make the final decision; often, this involved seeking help from additional referees. In addition, papers whose authors included a member of the conference program committee were evaluated using the double-blinded review process. One exception to the above evaluation process was for papers that were submitted directly to chairs/organizers of pre-approved sessions/workshops; in these cases, the chairs/organizers were responsible for the evaluation of such submissions. The overall paper acceptance rate for regular papers was 28%; 16% of the remaining papers were accepted as poster papers (at the time of this writing, we had not yet received the acceptance rate for a couple of individual tracks.) We are very grateful to the many colleagues who offered their services in organizing the conference. In particular, we would like to thank the members of Program Committee of ESCS’17, members of the congress Steering Committee, and members of the committees of federated congress tracks that have topics within the scope of ESCS. Many individuals listed below, will be requested after the conference to provide their expertise and services for selecting papers for publication (extended versions) in journal special issues as well as for publication in a set of research books (to be prepared for publishers including: Springer, Elsevier, BMC journals, and others). • • • • • •

Prof. Nizar Al-Holou (Congress Steering Committee); Professor and Chair, ECE Department; Vice Chair, IEEE/SEM-Computer Chapter; University of Detroit Mercy, Detroit, Michigan, USA Prof. Hamid R. Arabnia (Congress Steering Committee); Graduate Program Director (PhD, MS, MAMS); The University of Georgia, USA; Editor-in-Chief, Journal of Supercomputing (Springer); Fellow, Center of Excellence in Terrorism, Resilience, Intelligence & Organized Crime Research (CENTRIC). Prof. P. Balasubramanian; School of Computer Engineering, Nanyang Technological University, Singapore Prof. Dr. Juan-Vicente Capella-Hernandez; Universitat Politecnica de Valencia (UPV), Department of Computer Engineering (DISCA), Valencia, Spain Prof. Kevin Daimi (Congress Steering Committee); Director, Computer Science and Software Engineering Programs, Department of Mathematics, Computer Science and Software Engineering, University of Detroit Mercy, Detroit, Michigan, USA Prof. Leonidas Deligiannidis (Congress Steering Committee); Department of Computer Information Systems, Wentworth Institute of Technology, Boston, Massachusetts, USA; Visiting Professor, MIT, USA

• • • • • • • • • •

•

• •

•

Prof. Mary Mehrnoosh Eshaghian-Wilner (Congress Steering Committee); Professor of Engineering Practice, University of Southern California, California, USA; Adjunct Professor, Electrical Engineering, University of California Los Angeles, Los Angeles (UCLA), California, USA Prof. Houcine Hassan; Department of Computer Engineering (Systems Data Processing and Computers), Universitat Politecnica de Valencia, Spain Prof. Dr. Guoming Lai; Computer Science and Technology, Sun Yat-Sen University, Guangzhou, P. R. China Dr. Andrew Marsh (Congress Steering Committee); CEO, HoIP Telecom Ltd (Healthcare over Internet Protocol), UK; Secretary General of World Academy of BioMedical Sciences and Technologies (WABT) a UNESCO NGO, The United Nations Dr. Ali Mostafaeipour; Industrial Engineering Department, Yazd University, Yazd, Iran Prof. Dr., Eng. Robert Ehimen Okonigene (Congress Steering Committee); Department of Electrical & Electronics Engineering, Faculty of Engineering and Tech., Ambrose Alli University, Edo State, Nigeria Dr. Benaoumeur Senouci (Vice Chair, ESCS); Embedded Systems Department, LACSC Laboratory- Central Electronic Engineering School, ECE, Paris, France Ashu M. G. Solo (Publicity), Fellow of British Computer Society, Principal/R&D Engineer, Maverick Technologies America Inc. Prof. Fernando G. Tinetti (Congress Steering Committee); School of CS, Universidad Nacional de La Plata, La Plata, Argentina; Co-editor, Journal of Computer Science and Technology (JCS&T). Prof. Hahanov Vladimir (Congress Steering Committee); Vice Rector, and Dean of the Computer Engineering Faculty, Kharkov National University of Radio Electronics, Ukraine and Professor of Design Automation Department, Computer Engineering Faculty, Kharkov; IEEE Computer Society Golden Core Member; National University of Radio Electronics, Ukraine Prof. Shiuh-Jeng Wang (Congress Steering Committee); Director of Information Cryptology and Construction Laboratory (ICCL) and Director of Chinese Cryptology and Information Security Association (CCISA); Department of Information Management, Central Police University, Taoyuan, Taiwan; Guest Ed., IEEE Journal on Selected Areas in Communications. Prof. Layne T. Watson (Congress Steering Committee); Fellow of IEEE; Fellow of The National Institute of Aerospace; Professor of Computer Science, Mathematics, and Aerospace and Ocean Engineering, Virginia Polytechnic Institute & State University, Blacksburg, Virginia, USA Prof. Hyun Yoe; Director of Agrofood IT Research Center and Vice President of Korea Association of ICT Convergence in the Agriculture and Food Business (KAICAF); Director of Agriculture IT Convergence Support Center (AITCSC); Department of of Information and Communication Engineering, Sunchon National University, Suncheon, Republic of Korea (South Korea) Prof. Jane You (Congress Steering Committee); Associate Head, Department of Computing, The Hong Kong Polytechnic University, Kowloon, Hong Kong

We would like to extend our appreciation to the referees, the members of the program committees of individual sessions, tracks, and workshops; their names do not appear in this document; they are listed on the web sites of individual tracks. As Sponsors-at-large, partners, and/or organizers each of the followings (separated by semicolons) provided help for at least one track of the Congress: Computer Science Research, Education, and Applications Press (CSREA); US Chapter of World Academy of Science; American Council on Science & Education & Federated Research Council (http://www.americancse.org/); HoIP, Health Without Boundaries, Healthcare over Internet Protocol, UK (http://www.hoip.eu); HoIP Telecom, UK (http://www.hoip-telecom.co.uk); and WABT, Human Health Medicine, UNESCO NGOs, Paris, France (http://www.thewabt.com/ ). In addition, a number of university faculty members and their staff (names appear on the cover of the set of proceedings), several publishers of computer science and computer engineering books and journals, chapters and/or task forces of computer science associations/organizations from 3 regions, and developers of high-performance machines and systems provided significant help in organizing the conference as well as providing some resources. We are grateful to them all. We express our gratitude to keynote, invited, and individual conference/tracks and tutorial speakers - the list of speakers appears on the conference web site. We would also like to thank the followings: UCMSS (Universal Conference Management Systems & Support, California, USA) for managing all aspects of the conference; Dr. Tim Field of APC for coordinating and managing the printing of the proceedings; and the staff of Monte Carlo Resort (Convention department) at Las Vegas for the professional service they

provided. Last but not least, we would like to thank the Co-Editors and Associate Co-Editors of ESCS’17: Prof. Hamid R. Arabnia, Prof. Leonidas Deligiannidis, and Prof. Fernando G. Tinetti. We present the proceedings of ESCS’17.

Steering Committee, 2017 http://americancse.org/

Contents SESSION: SOFTWARE TOOLS AND SYSTEMS, NOVEL APPLICATIONS, AND REAL-TIME SYSTEMS Analyzing Real-Time Java: Deadline Experiments and Comparison with C Fernando G. Tinetti, Demian Klc, Fernando L. Romero

3

Safety-Driven Cyber Security Engineering Approach Applied to OTA Ahmad Nasser, Di Ma, Sam Lauzon

8

Modeling Scheduling Policy with Constraint Satisfaction Problem Approach Hyuk Lee, Jin-Young Choi

14

SESSION: CYBER-PHYSICAL SYSTEMS AND APPLICATIONS Shortest Job First Scheduling for Reducing Jitter in Cyber Physical Systems JiYoung Heo, Moonju Park

23

Electronic Water Billing System Mark Ehab Shoukry, Michael Maher Ibrahim, Maher Mansour Abdel-Aziz

29

SESSION: EMBEDDED SYSTEMS, FPGA, NOVEL APPLICATIONS AND TOOLS Transforming Ladder Logic to Verilog for FPGA Realization of Programmable Logic Controllers Giancarlo Corti, Drake Brunner, Naoki Mizuno, Peter Jamieson

35

Prototype System of Low-cost LED Lighting Vision Inspection Based On Image Processing SungHo Ahn, YoonJeong Song

39

RPM Measurement using 3-Axis Digital Magnetometer Tongjun Ruan, Robert Balch

42

Multi-FPGA Platform for Smart Automobiles Embedded Electronics Design and Prototyping 49 Anouchka Guillot, Amin Jallouli, Audrey Ly, Aline Sayarath, Lucas Rezakhanlou, Quentin Cabanes, Benaoumeur Senouci Smart Communication System for Deaf-Dumb People Mina M. Abdel-Masieh, Manuel M. Nasif, Maher Mansour Abdel-Aziz

54

SESSION: LATE PAPERS - EMBEDDED SYSTEMS AND APPLICATIONS Embedded Databases David Cox

59

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

SESSION SOFTWARE TOOLS AND SYSTEMS, NOVEL APPLICATIONS, AND REAL-TIME SYSTEMS Chair(s) TBA

ISBN: 1-60132-455-3, CSREA Press ©

1

2

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Analyzing Real-Time Java: Deadline Experiments and Comparison with C Fernando G. Tinetti1, Demian Kĺč, Fernando L. Romero III-LIDI, Fac. de Informática Universidad Nacional de La Plata 1 Also with Comisión de Investigaciones Científicas Prov. de Bs. As. La Plata, Argentina

Abstract—We have designed and implemented a set of experiments in order to compare a Real-Time Java (RT Java) virtual machine implementation with plain Real Time Linux (i.e. Linux + rt-preempt patch). Given the characteristics of real-time execution and applications, we consider the specific code and/or benchmarks as important as the runtime and environment configurations for performance evaluation (as well as for production environments, as a matter of fact). Experiment results are compared, for obtaining RT Java overhead over realtime Linux with plain C programming. Besides usual hardware and basic real-time Linux configurations, we explain some specific details of RT Java that should be taken into account in all RT Java implementations, such as the garbage collector and its impact on meeting time constraints. We experiment with Real Time Java and compare results with similar or the same experiments using the C language, the de facto standard in realtime computing. Even when different languages are used, the main metric is the one used in the real-time field: missed/met deadlines. We mostly used standard experimentation programs and developed a specific one for having fair timing comparison among experiments. Keywords—Real-Time Java, Real-Time Systems, IoT, Hard and Soft Real-Time Deadlines

I. INTRODUCTION Real-time systems and applications are being analyzed since decades ago [6] [7] [17] [19] [30]. Today, many of the systems and applications formerly considered in the real-time area are now considered part of classical mission-critical applications [6] [7], Internet of Things (IoT) [12] [31], embedded systems [9] [19] [17] and other areas. Even when each area has its own specific details and requirements, all have several common issues beyond its relationship with realtime processing. Among those common issues, the software development languages, libraries, and environment should be considered from the software productivity point of view. High level object oriented languages such as Java are considered the most appropriate from the point of view of software production [25] [8]. However, those high-level language and libraries are complex to analyze and implement for real-time processing [23] [6] [30].

While the well-known undebatable baseline for real-time processing is at the real-time operating system (RTOS) level, the software development process is still a problem. Once the operating system is able to provide the minimum facilities for real-time computing/determinism such as the Linux rt-preempt patch [11] [24], several aspects of software development have to be considered at the same time, and most of them depend on each other. Java is considered a high level, stable, and popular programming language, and efforts have been made to take advantage of those characteristics in many different applications [18] [29] [4]. Also, there has been a sustained effort for developing a Real-Time Specification for Java (also known as RTSJ), which initially produced the current stable 1.0.2 version [28] [5] and the 2.0 version is currently being defined [15]. Besides having a current stable specification, it is possible to use several implementations, one of which is the socalled JamaicaVM [1]. Our main work is focused on defining a set of programs and environment scenarios for analyzing periodic tasks deadline/s. We use as many well-known programs/benchmarks as possible, and define a new one only if necessary. Our scenarios set several parameters such as real-time threads, priorities, and free/overloaded system so that it is possible to have a broad (while manageable) number of tests and possible runtime environments. We also focus our work mostly in hard real-time applications, since they have the most constrained requirements in terms of real-time deadlines (i.e. a failure in meeting the deadline is considered catastrophic). Even when focused in hard real-time tasks, we are able to take into account soft real-time tasks. Soft real-time tasks are those for which missing a deadline is not considered as catastrophic, but the system response is losing quality/usefulness as the elapsed time is longer than that defined as the required by the application. Once again, a predictable computing system/task is preferred over a fast computing system/task in the context of real-time computing, so minimum jitters are expected in the elapsed time taken by the system as a reaction to an external event and for processing periodic tasks. Even when real-time systems are well defined, it is not always possible to take into account all possible scenarios a priori. Thus, specific programs/benchmarks are defined and used in order to have a better understanding of system behavior

ISBN: 1-60132-455-3, CSREA Press ©

3

4

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

in different scenarios. We start including in this paper those we consider useful in the context of RT Java specification and implementation, so that it is possible to be compared with a plain Linux with rt-patch programmed in C. As an initial approach, we have also taken some measurements in non realtime systems just to have experimental data of the timing constraints and system performance. RT Java includes several requirements for implementations that make it useful for real-time systems. Among the most useful definitions we could identify [28] [5]: • Fixed priority scheduling (with preemption). • Memory definitions and garbage collector scheduling: garbage collector is preempted if necessary and has more information about memory used by objects. • Real time threads and asynchronous event handlers, so that the scheduler has precise information about activation times (e.g. periodic tasks). • Priority inversion handling/avoidance via an abstract class with subclasses defined for different priority inversion avoidance algorithms. And we should take advantage of/configure all of them in our experiments. It is worth mentioning that all the RT Java definitions are useful only if running in top of a real-time operating system, otherwise it is not possible to maintain runtime predictability. II. RELATED WORK Most of the work in the real time computing area has been developed at the embedded and/or operating system level, as reflected in current bibliography [6] [7] [9] [11] [12] [17] [19] [30] [31]. Most of those books/publications are currently used in real-time computing and/or programming courses at University graduate and post-graduate levels. Java real-time programming can be considered as starting, even when there is registered work on Java Specification Requests since about two decades ago [27]. Most of the problems are due to the “gap” between the specification, which usually imposes specific requirements, and actual implementations, which must successfully meet those requirements. And the real-time field has quantitative requirements not always simple to satisfy. Having well defined Real-Time Specifications for Java as its current 2.0 version [15], it has been important to implement and evaluate real-time applications. Some of the effort is reflected in currently referenced books, such as [5] [6]. Most of the work is devoted to software engineering, such as those mentioned above as well as [14] [21] [22]. Furthermore, several previous publications are directly focused on specific implementations, such as [10] [26] [13]. Our proposal is to provide several experiments, measurements, and settings/scenarios for advancing and/or getting new insight over those previously published works while being independent of specific products/implementations. Since the real-time experiments are well-known in the realtime Linux environment, we will do our best effort to have similar experiment/s in the real-time Java environment.

III. EXPERIMENTS: CODE AND ENVIRONMENT Clearly, the underlying execution environment must be a real-time one. We have chosen Linux with rt-patch because it is a real-time operating system, and it is widely known and available for a large number of computing platforms. Real-time computing in this environment is straightforward, since it handles/directly implements the most necessary facilities such as threads, priorities, preemption, etc. [11]. The standard and most useful benchmark is used in this environment: cyclictest [20], along with also well-known auxiliary programs: taskset (for handling process/threads affinity) and stress (for computer workload, so that the system is fully loaded while using the benchmark) [16]. Thus, Fig. 1 schematically shows the experiment environment in real-time Linux.

cyclictest | [stress] real-time Linux (Linux + rt-preempt patch) Hardware (Energy saving options disabled) Figure 1: Real-Time Linux Environment. We have chosen JamaicaVM as the real-time Java experiment execution environment because: a) it implements Java, b) it also implements a significant fraction of the RTSJ as well as some RTSJ extensions, such as a real-time garbage collector [2], and c) it is available for free in its Personal Edition version. The JamaicaVM documentation clearly describes the limitations of the RTSJ implementation as well as specific JamaicaVM implementation details beyond the RTSJ. Thus, portability issues are easily identified and can be solved in advance, and the JamaicaVM environment also includes a switch for controlling strict RTSJ compliance. The basic benchmark used in the JamaicaVM is similar to cyclictest, called jittertest [3]. However, we have developed one more benchmark srtp (from “simple real-time period”) in order to measure the elapsed time since the activation of a periodic realtime thread and the beginning of its real execution. Neither RTSJ nor JamaicaVM provide a way to measure the “waiting time” since a thread gets the scheduler ready queue (activation time) and it effectively begins to use the CPU (CPU execution runtime). Actually, this simple and specific benchmark was developed for obtaining the same experimental data as that provided by cyclictest. The key point of the srtp is starting at a specific time and, given that periodic tasks should be activated at specific times (defined by a static parameter), the latency is computed as shown in Eq. (1), where • rst: real start time, taken by the thread itself as the experiment advances. • cdt: cyclic determined time, i.e. the time at which the thread should have started is execution (using the CPU).

ISBN: 1-60132-455-3, CSREA Press ©

y = rst − cdt

(1)

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Fig. 2 schematically shows the experiment environment in a real-time Java virtual machine running in a real-time Linux.

In Fig. 3, the measured delay times are shown on the x-axis and the number of occurrences are shown on the y-axis, with an interval of 500 µsec: • No RT: a standard Linux operating system without rtpreempt patch. As expected, it has the worst results, with a maximum delay of 380 µsec.

jittertest | srtp JamaicaVM | [stress] real-time Linux (Linux + rt-preempt patch) Hardware (Energy saving options disabled) Figure 2: Java Real-Time Environment. All experiments are carried out in a relatively current hardware computer: AMD A10-6800K APU (4 CPUs) @4120 MHz, 16 GB de RAM, Linux Ubuntu 14.04 LTS 64 bits, vanilla kernel 3.14.39 (which is patched later with the rtpreempt patch). The rt-patched kernel has been compiled with the following settings: a) disable dynamic ticks, b) disable latency tracing, c) disable energy saving options (except those from the ACPI module), d) enable high resolution timers, and fully preemptable kernel. Also, some BIOS have been changed: a) disable CPU throttling, b) set clock to “extreme mode” (max. frequency). Finally, the Linux kernel startup option idle=poll was set to avoid further interference of energy saving kernel features. Unfortunately, there are multiple energy saving options set at different levels (kernel compile, computer BIOS, and kernel load parameter). Furthermore, those specifically unrelated with the Linux kernel (i.e. at the BIOS) may depend on the specific hardware (motherboard) provider. IV. EXPERIMENTS: RESULTS Initially, some preliminary results will be shown, with measurements taken over short-periods of time (a few seconds/ minutes). Fig. 3 shows different cyclic test short-time experiment scenarios, some of them as a quantitative reference of possible problems meeting deadlines in non real-time environments.

• No RT Stressed: adding workload to the standard Linux system so that no CPU is idle during the experiment. As expected, the result in terms of maximum delay is worse than the same scenario without stress: 393 µsec. • RT: a real-time Linux without stress. The maximum delay is drastically reduced to 66 µsec. • RT Stressed: adding stress to a real-time Linux implies a degradation of the maximum delay of about 12%: 74 µsec. Fig. 4 shows the jittertest results with stress (JamaicaVM running on real-time Linux). The period was set to 150 µsec and the maximum measured period was 271.13 µsec. Period measurements are computed as the times between two releases [3], which is not what we are interested in, since we want to compare delays with the cyclictest benchmark. Therefore, we are going to use our own srtp benchmark thus avoiding indirect comparison/s.

Figure 4: Stressed System jittertest Results. After having the previous set of preliminary experiments, we have decided to use the cyclictest benchmark for 24-hours experiments and use our own srtp benchmark for direct comparison of results. The cyclictest is used on real-time Linux and srtp is used on a JamaicaVM running as a real-time process in the same real-time Linux. In both scenarios, the stress utility is used for overloading the system with many low priority processes/threads. Fig. 5 shows the cyclictest results over 24 hours in a mostly idle (non-stressed) real-time Linux. The maximum delay time was measured as 38µsec. The cyclictest results over 24 hours in a stressed (i.e. running the stress utility so that every CPU has some thread available to run) real-time Linux are shown in Fig. 6. In this scenario, the maximum delay time was measured as 46µsec, i.e. about 21% worse than that for the non-stressed environment.

Figure 3: Preliminary cyclictest Results.

ISBN: 1-60132-455-3, CSREA Press ©

5

6

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

comparison, so the difference is not due to noise generated by indirect timing derivations.

Figure 7: 24-Hours srtp Results with Stress. Figure 5: 24-Hours cyclictest Results without Stress.

Even when the real-time Java implementation effectively has worse delays than those in the real-time Linux, there is a strong indication of real-time performance. Even under stress (by overloading the system with a specific program, so that it is not possible that a CPU is idle) the delay measurements are highly concentrated in the interval 50-70µsec, only a few delays are greater than the upper bound of that interval, and all delays are below 150µsec. Therefore, it is possible to identify 150µsec as a lower bound for hard real-time computing in this environment. It is worth noting that the lower bounds for hard real-time processing identified by cyclictest and srtp in the different environments depend at least on hardware details. However, both benchmarks provide a methodological way of having the specific bounds in the specific hardware to be used.

Figure 6: 24-Hours cyclictest Results with Stress. All the long-term (24-hours) experiments show that most delays are below 20µsec. Take into account that the y-axis in Fig. 4 and Fig. 5 above is in logarithmic scale. The 24-hour stressed experiment is particularly useful. Based on those results, we would be able to determine that the system handles hard real-time processing tasks with deadlines not minor than 50µsec. Fig. 7 shows the experiment measurements using srtp on a JamaicaVM running in a real-time Linux with stress, with a maximum delay of less than 150µsec. The y-axis in Fig. 7 is the % of delay measurements taken in µsec shown in the x-axis. Experiment measurements are almost the same for the non-stressed runtime environment. Clearly, most of the delays are between 50 and 70 µsec, but the system would not able to handle hard real-time tasks with deadline below 150µsec. The overhead/greater delay time measured in the JamaicaVM is clear: only a few thread delays were below 50µsec, while in the real-time Linux all the measurements made with cyclictest are clearly below 50µsec. The srtp benchmark allows direct timing

V. CONCLUSIONS AND FURTHER WORK We have measured experimental real-time bounds in a specific Real-Time Specification for Java implementation (JamaicaVM). We are able to compare performance with the “native” real-time Linux because we have implemented a specific benchmark program. Actual experiments have shown that • RTSJ implementation performance provides a strong environment for real-time computing, since there are not unbound delays in long-term experiments under heavy workloads. • RTSJ implementation performance is about three times worse than native real-time Linux performance in terms of bounded delay time. We expect to improve our experiments in terms of having different evaluated hardware. Thus, it will be possible to analyze the relative performance differences (whether they are similar or change depending on the underlying hardware). Also, it should be possible to develop a specific benchmark for real-time Linux so that it will be possible to directly compare jittertest-like performance values obtained in an application developed in C for real-time Linux.

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

REFERENCES [1] [2] [3] [4]

[5] [6]

[7] [8] [9] [10]

[11] [12]

[13]

[14] [15]

[16]

Aicas GmbH and aicas incorporated, Aicas JamaicaVM, https://www.aicas.com/cms/en/JamaicaVM, (Feb. 2016). Aicas GmbH, JamaicaVM 8.0 — User Manual: Java Technology for Critical Embedded Systems, 2016. Aicas GmbH and aicas incorporated, Benchmarks | aicas.com, Jitter test, https://www.aicas.com/cms/en/benchmarks, (Feb. 2016). B. Bruegge, A. H. Dutoit, Object-Oriented Software Engineering Using UML, Patterns, and Java, 3rd Edition, Pearson, 2009, ISBN-10: 0136061257. E. J. Bruno, G. Bollella, Real-Time Java Programming: With Java RTS, Prentice Hall, 2009, ISBN-10: 0137142986. A. Burns, A. Wellings, Real-Time Systems and Programming Languages: Ada, Real-Time Java and C/Real-Time POSIX, 4. AddisonWesley, 2009. G. C. Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms, and Applications, 3. Springer, 2011. Bruce Eckel, Thinking in Java, 4. Pearson, 2006. X. Fan, Real-Time Embedded Systems: Design Principles and Engineering Practices, Newnes, Feb. 2015. S. C. Foley, Developing with real-time Java, Part 1: Exploit real-time Java's unique features, http://www.ibm.com/developerworks/ java/library/j-devrtj1/index.html L Fu, R. Schwebel. RT PREEMPT HOWTO, https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO B. Graham, M. Weinstein, The RTOS as the Engine Powering the Internet of Things, WindRiver White Paper, Wind River Systems, Inc ., Feb. 2014, available at http://www.intel.com/content/www/us/en/ internet-of-things/white-papers/ real-time-operating-system-for-iot.html A. Hall, A. Stevens, Developing with real-time Java, Part 3: Write, validate, and analyze a real-time Java application, http://www.ibm.com/developerworks/java/library/j-rtjdev3/index.html M. T. Higuera-Toledano, A. J. Wellings, Distributed, Embedded and Real-time Java Systems, Springer; 2012, ISBN-10: 1493900390. Java Community Process (JCP), SR-000282 Real-Time Specification for Java 2.0 Draft 12, Early Draft Review 2, 2015 http://download.oracle.com/otndocs/jcp/rtsj-2_0-edr2-spec/index.html A. Kili, How to Impose High CPU Load and Stress Test on Linux Using

[17] [18] [19] [20] [21]

[22]

[23] [24]

[25] [26]

[27]

[28]

[29]

[30] [31]

‘Stress-ng’ Tool, Tecmint: Linux Howtos, Tutorials & Guides, 2015, http://www.tecmint.com/linux-cpu-load-stress-test-with-stress-ng-tool/ H. Kopetz, Real-Time Systems: Design Principles for Distributed Embedded, Applications, 2. Springer, 2011. J. Lewis, W. Loftus, Java Software Solutions, 8th Ed., Pearson, 2014, ISBN-10: 013359495. Q. Li, C. Yao, Real-Time Concepts for Embedded Systems, 1. CRC Press, 2003. Linux Foundation Wiki, Cyclictest, https://wiki.linuxfoundation. org/realtime/documentation/howto/howto_rt_tools_cyclictest K. Nilsen, Developing Real-Time Software with Java SE APIs: Part 1, 2014, http://www.oracle.com/technetwork/articles/java/ nilsen-realtimept1-2264405.html K. Nilsen, Developing Real-Time Software with Java SE APIs: Part 2, 2014, http://www.oracle.com/technetwork/articles/java/ nilsen-realtimept2-2264409.html Scott Oaks, Java Performance: The Definitive Guide, 1. O'Reilly, 2014. Open Source Automation Development Lab, OSADL Project: Realtime Linux, https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html Herbert Schildt, The Java Complete Reference, 9. Oracle Press, 2014. M. Stoodley, C. Gracie, Developing with real-time Java, Part 2: Improve service quality, 2009, http://www.ibm.com/developerworks/ java/library/j-devrtj2/index.html Sun Microsystems, Inc. The Java Community Process Program, 1998, https://jcp.org/aboutJava/communityprocess/java_community_process.h tml The Real Time for Java Expert Group, Real Time Specification for Java Version 1.0.2, 2006, http://www.rtsj.org/specjavadoc/book_index.html J. Visser, S. Rigal, R. van der Leek, P. van Eck, G. Wijnholds, Building Maintainable Software, Java Edition: Ten Guidelines for Future-Proof Code, O'Reilly Media, 2016, ISBN-10: 1491953527. A. Wellings, Concurrent and Real-Time Programming in Java, 1. John Wiley & Sons, 2004. L. Wood, “Real-time computing: Gateway to the Internet of Things?”, Computerworld, Aug 2015, available at http://www.computerworld.com/article/2973986/high-performancecomputing/real-time-computing-gateway-to-the-internet-of-things.html

ISBN: 1-60132-455-3, CSREA Press ©

7

8

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Safety-Driven Cyber Security Engineering Approach Applied to OTA Ahmad MK Nasser

Dr. Di Ma

Sam Lauzon

Department of Computer and Information Science University of Michigan-Dearborn

Department of Computer and Information Science University of Michigan-Dearborn

University of Michigan Transport Institute-Ann Arbor

[email protected]

[email protected]

ABSTRACT Automotive ECUs rely on the convenience of flashing new software updates both during the development and the post production phases, when updates are needed to fix bugs or add functionality. As vehicles become connected to the Internet and to smart devices, more capabilities for delivering the flash update to the vehicle are possible at the added cost of increased security threats. In this paper we present a safety driven security engineering approach to close the gap between safety and security as it applies to cyber physical systems. We then apply it to the software update over-theair (OTA) use case. The approach presented aims to fill the gap of applying traditional IT security techniques to Cyber Physical Systems where safety is a critical factor. We compare the results of our approach to other work that aims to secure the OTA process to determine the efficacy of our approach.

Keywords OTA, Automotive Cyber Security, Safety, EVITA, ISO26262

1.

INTRODUCTION

In recent years, there have been several calls to either combine safety and security in a single process, or to define touch points between the two when performed in parallel [2],[5],[8],[9]. A complete safety and security engineering process is still a subject of research. In this paper we present a novel safety driven security approach. We then apply it to a practical use case, namely the connected software update process in order to prove the efficacy of our approach. A connected software update process is defined as one in which the software update is delivered to the vehicle wirelessly or through a connected device to be later flashed into a target ECU over the vehicle network. Reduction of recall costs, the migration towards ADAS and autonomous driving, the capability to download security patches, as well as the possibility of upgrading vehicle features wirelessly, all make the connected software update a mandatory building block to support the future of vehicle development. However, with connectivity comes the threat of downloads of malicious software which can have severe impacts on safety. Malware may be delivered to the vehicle when a vulnerability exists in the OTA update process, flaws in embedded web browsers, malicious aftermarket equipment, or through removable media ports and others [12]. The famous Jeep UConnect attack by Miller and Valasek [6], used a software

[email protected]

update vulnerability in the head unit in order to modify the firmware of the vehicle processor interface, which could then interfere with the CAN bus via the park assist module. The latter would send a diagnostic command to bleed the brakes causing the vehicle to lose braking ability at low speeds. This and other similar proven attacks demonstrate the need for securing the entire software update process in a way that is safety focused, which is what we will attempt to do in this paper.

1.1

Contributions:

A major differentiating factor of an automobile from other IT systems is the additional concern about safety, due to the ability to cause damage or injury to property and human life. While several papers have discussed OTA security, we are the first to propose a safety driven approach to security and apply it to OTA. The approach, shown in figure 2, starts after the safety assessment has been completed, and uses the safety goals as inputs to the security analysis. Next we define the attacker model relative to the safety goals. From there we can derive the attack methods that can violate the safety goals. Subsequently we can address those attacks through detection and prevention countermeasures. If prevention is possible, then we can derive the technical security requirements to achieve that. If for specific attacks only detection is possible, the action taken has to factor in putting the system back in a safe state to satisfy the safety concept. Our main contribution is in defining a new approach that simplifies the security engineering process in Automotive applications and leverages the work done in the functional safety area.

1.2

Organization:

Section 2 presents a brief survey of related work done to analyze security threats that face the software update process. Section 3 presents the assumed architecture for our analysis. In Section 4 we introduce our safety driven approach to the security analysis. We then apply the phases of the approach to the connected software update in order to derive the security requirements needed to safeguard the software update process. Finally, we conclude the paper in section 6 and provide our vision for future work.

2.

RELATED WORK

SAE J3061 [9], advocates for a security process that aims to lower the risk of a successful attack similar to how ISO26262 [3] aims to lower the risk of a safety hazard. It provides a framework for implementing a cybersecurity engineering process that traces security in automotive systems from fea-

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

ture definition, to threat analysis and functional security requirements, similar to how functional safety considers hazards and derives safety requirements. This parallelism is further demonstrated in the work of Burton in [2] where the security engineering process is traced over the V model to show how safety and security can have analogous activities. Other initiatives like HEAVENS [1] and EVITA [8], define threat assessment models that factor in the safety impacts of threats. The EVITA project [8], defined ten attack trees based on eighteen use cases which are considered representative of the type of attack scenarios on vehicle assets. Besides developing attack trees, the study went on to prioritize security requirements based on the attack potential and the risks that arise due to each attack. By assigning a probability to each attack, the research aimed to give the user a chance to focus on the attacks that are most probable and also with the highest severity. In all the previous work, the definition of how safety and security shall interact remains an open problem. In terms of OTA security, there has been significant work done to propose a secure OTA system for vehicles. The EVITA project [8] derives the following security requirements for firmware updates between the OEM, a Download Tool (DT), a Communication Control Unit (CCU) and an ECU:

1. Preventing impersonation of the portal by using certificate based identity verification of the portal and preloading the portals public key in the vehicle 2. Usage of an IDS in the portal to detect an intrusion and take the proper action 3. Secure end-to-end communication over the wireless link by encrypting all the data with a freshness counter to prevent packet injection or playback 4. Preventing impersonation of a vehicle by establishing the vehicle identity through a certificate 5. Usage of a firewall and an IDS in the vehicle to alert against an intrusion and log the intrusion to prevent future breaches In the above requirements, safety is assumed as a by product of securing the system but is not factored in the design process. Uptane [4], is a recent open source project that has suggested a full OTA solution specifically designed for automotive systems. The project enlisted security experts from academia as well as experts from the automotive industry to come up with a state of the art open source solution to OTA. The project presents the following design goals to deal with security attacks:

1. Firmware confidentiality (CSR.1): Firmware must be kept confidential when transferred from OEM to DTool from DT to the target ECU

1. Leverage additional storage to recover from endless data attacks. This allows the new software image to be flashed without overwriting the original image which can serve as a backup.

2. Key confidentiality (CSR.2): Exchanges transferring or using non-public keys must preserve key secrecy along the whole flashing process

2. Broadcast metadata to prevent mixed-bundles attacks where a compromised primary can send incompatible software images to secondary ECUs

3. Internal Authenticity (ASR.1): Whenever an exchange between CCU and ECU happens, the correspondence between claimed and real authors must be authenticated 4. External Authenticity (ASR.2): Whenever data is exchanged between DT utility and OEM server or between DT and in-car components, the correspondence between claimed and real authors must be authenticated. The above requirements do not make a distinction between safety relevant security requirements and those which are purely security relevant. The authors in [7], study the different security threats that face software updates and present a list of threats based on the different elements involved in the flash update process, which are: the portal, the communication link between the portal and the vehicle, and vehicle security risks. In the portal, they point to masquerading attacks in which an attacker takes-over or creates a fake portal to distribute malicious software packages. In the communication link, they point to the risk of the wireless link being vulnerable to traffic manipulation through packet injection and replay attacks. As for the vehicle security risks, they point to the case where an attacker can impersonate a vehicle and connect to the portal to uncover security vulnerabilities or attack vectors. These vectors can then result in further intrusion attacks. The authors derive security requirements to address those risks in a methodical fashion:

9

3. Utilize a vehicle version manifest to detect partial bundle installation attacks which can leave ECUs partially programmed 4. Use a time server to limit freeze attacks to prevent an ECU from completing its download or preventing it from receiving any updates The above design goals guide the full implementation of Uptane which defines in greater detail the roles of primaries, secondaries, and the content of meta data. In this paper we will show how our approach differs from existing processes for harmonizing safety and security, by applying it to the OTA process. We will use Uptane as a reference, as it is the latest and most complete published solution to OTA.

3.

ARCHITECTURE

The connected software update allows the remote delivery of software updates to an ECU in a vehicle. Whether the update is delivered over the air, for example through a telematics unit or through a Bluetooth enabled smart device, direct authentication with the originating source is needed to ensure the integrity and authenticity of the software update. In this paper when we discuss over the air update, we are referencing the process by which software updates are delivered to a vehicle wirelessly first by downloading to a primary ECU like the vehicle gateway, and second by flashing the target ECU.

ISBN: 1-60132-455-3, CSREA Press ©

10

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Figure 1: Architecture of OTA system considered for the security analysis The architecture shown in figure 1, is a simplified diagram of the vehicle data architecture which results in the following attack surfaces: OBD-II Port: 1. Download tool connected to the OBD-II connector

Figure 2: Safety driven secure engineering process

2. Aftermarket equipment connected to OBD-II port (Insurance Dongle) Telematics/Headunit: 1. 3G/4G Connection 2. Wifi Hotspot (and related software) 3. Bluetooth connection to mobile device 4. Media Ports (USB, SD Card, CD/DVD) Internal Vehicle network: 1. CAN bus network 2. Compromised ECU, either gateway or ECU on safety bus In the following sections we will see how this architecture results in a set of threats that have safety impacts and how they can be mitigated.

4.

SAFETY-DRIVEN SECURITY APPROACH

In [2], Burton presents a real example of extending the safety standard ISO26262 to address security threats against the adaptive cruise control ECU. In this paper we shall use a similar method to evaluating our security engineering approach by applying it to the connected software update process. One main benefit of doing so is to give a practical application of the safety driven security engineering approach and to evaluate its advantages and disadvantages. The approach can be summarized in figure 2.

Table 1: Simplified Hazard Analysis for OTA Hazard Functional Unit Software is corrupted during the CCU, Gateway, Tardownload process without detection get ECU by the ECU. ECU then executes corrupted code which can result in undefined and potentially unsafe behavior Download of incompatible binary Gateway, Target files for e.g. a calibration file with ECU unsafe parameter settings A communication failure prevents Gateway, Target the download from completing leav- ECU ing a safety critical ECU unprogrammed A power failure during program- Gateway ECU, Tarming leaves a safety critical get ECU ECU partially programmed or un-programmed A permanent communication fail- CCU ure in the system prevents any updates from reaching the vehicle including safety critical patches, e.g. recall related updates

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Attacker Organized Crime Terrorist Cyber Activists

Cyber Criminals

11

Table 2: Safety Driven Attacker Model Objective Impact Download Malware to control an individual vehi- Injury or Loss of Life to Individual Car cle of victim Download Malware to control fleets of vehicles to Injury or Loss of Life to civilian or government cause mass chaos vehicles Disrupt OTA process to prevent safety critical Loss of customer confidence in OTA, potential for patches or vulnerability patches from being in- injury or loss of life if manual update not perstalled formed Reflash ECUs remotely without ability to sign Loss of consumer confidence in ADAS systems, software, which leaves ECUs in bootloader and increased risk of injuries or loss of life mode(un-programmed state) i.e. without safety critical functionality .

First, we assume a hazard and risk analysis was performed and that safety goals have already been defined. Note safety goals are high level security requirements that an ECU needs to maintain to ensure the overall vehicle safety is achieved. We then proceed with defining the attacker model by describing attack objectives which can directly impact the identified safety goals. Here we are strictly focused on attackers who want to create a hazardous driving situation. Note, we assume that non safety threats, such as ones against privacy, are still worthy of studying, but these can be pursued via traditional IT security methods. Using the attack objectives, we can derive our attack methods. Here, there are several techniques to produce attack methods, for e.g. via attack trees as is done in the EVITA project [8], or by looking at documented attack methods in the Car Hacker’s Handbook [11]. Having a threat model such as STRIDE [10], can also be useful in enumerating threats that can lead to safety relevant attacks. Once, we have a set of attacks that can directly violate our safety goals, we can now evaluate whether each attack is preventable, or only detectable. For attacks that are preventable the next step is to define the technical security requirement at the component level to realize the attack countermeasure. If only detection is possible, we need to define the detection method as well as how the system shall react when the attack is detected. Since each attack is mapped to a specific safety goal, we can reuse the fail safe-states defined in the safety case to determine what the proper reaction shall be in the face of such an attack. The novelty of this approach is that it builds upon the safety case rather than follow a completely parallel and independent approach to the safety process with mere touch points that link the two. The approach we propose builds upon the premise that hazards cannot be added to the system through cyber attacks. Instead, the latter is only able to activate hazardous events that are possible for a specific ECU. Consider for e.g. a electronic power steering ECU which is required to mitigate the hazard of an over-steering event that can result from a failure in the input data of a steering sensor. An attacker can induce the hazard of over-steering for e.g. by spoofing the sensor data, but he cannot create a totally new hazard that is outside the physical limitations of the system. This makes the safety goals a good reference point to start our security analysis rather than searching the very large space of security threats only to find ones that can have a safety impact.

4.1

Safety Goals

As stated above, a prerequisite to analyzing the security threats which have safety implications on the software update process, is to define the safety goals first. Typically these are produced during the safety assessment. Since we do not have a real ECU or system we came up with our own safety goals based on a simplified hazard and risk analysis of the OTA system described in figure 1. The identified hazards are shown in table 1. Note, we did not assess risk levels of safety goals on this theoretical use case. This can be done on a full system when available. The list of hazards we identified lead us to the following consolidated safety goals for the OTA system: 1. Data corruption in software downloaded to the ECU shall not go undetected 2. Incompatible software images shall not be downloaded to an ECU without detection. 3. Safety critical ECUs shall never be permanently left in an un-programmed or partially programmed state as a result of an OTA event. An example is an airbag ECU, which if left in an un-programmed state would mean the absence of life saving features in case of an accident. 4. It shall always be possible to download an update to fix unsafe software or roll back to a safe version.

4.2

Attacker Model

In our safety driven security approach, the attacker objectives are to trigger hazardous events that violate the defined safety goals. This is presented in Table 2. Given our attacker objectives, we can derive three safetydriven attacks associated with the connected software update as shown in Table 3.

4.3

Functional Security Requirements

Depending on the security architecture, certain attacks may not be prevented but at least they can be detected and action can be taken. A security analysis shall evaluate each attack in terms of prevention and detectability in order to assign the proper action. Based on the attacks presented in Table 3, we propose the following functional security requirements: 1. The software download shall only be possible with authenticated data and from an authorized source

ISBN: 1-60132-455-3, CSREA Press ©

12

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Table 3: Attacks with safety Attack Description Download malware to take control of an ECU without detection Download a validly signed binary images with incompatible software Disrupt the update process indefinitely to prevent an update from reaching completion. Here the attacker may not be able to forge an authentic software image, yet he is still able to interfere with the software update process in a way to prevent critical software updates from being delivered or flashed to the target ECU. Manipulate the update process to result in an un-programmed ECU. In the case where the attacker cannot forge the signature of the software, he may try to disrupt the download so as to result in an unprogrammed ECU.

goal violations Safety Goal 1 2 3

4

2. The authenticity of the binaries shall include the compatibility information among binaries to prevent flashing incompatible software binaries 3. The OTA architecture shall permit multiple download channels to prevent safety critical updates from being blocked indefinitely through a single compromised channel 4. Failure to update safety critical ECUs shall not result in an un-programmed ECU, i.e. the system shall retain a backup copy of the software to be able to restore such ECUs to their previous functioning state It is interesting to note that the functional security requirements above seem to map very well to the design goals stated in Uptane [4] and shown in section 2. The differences are mainly in the technical requirements that Uptane defined dealing with the question of how to realize these requirements.

4.4

Technical Security Requirements

The mapping of functional security requirements to detection and prevention technical security requirements is a process that involves a complete system architecture and is outside the scope of this paper. In terms of leveraging the fail safe state in case of a non-preventable attack, the one example in our analysis was the attack that leaves the ECU un-programmed. In this case, the previous programming state is considered the safe state and therefore, by designing the system with additional backup memory where the previous software copy is stored and can be automatically activated, we are effectively defining the safe state of the system.

5.

CONCLUSION

The topic of safety and security overlap is still an active area of research. In this paper we presented a safety-driven

security engineering approach that is meant to close the gap between the two interdependent domains of functional safety and cyber security. We applied the approach to a popular use case, namely the OTA update. As a result, we produced a list of security requirements that was shown to be aligned with other studies that were carried out for the same use case. This promising result motivates us to investigate further how we can expand and fine tune this approach. By focusing on the safety goals first, we are able to separate threats that are not relevant to safety and can be addressed by traditional IT security approaches. This then guided us in defining safety relevant attacks and defining the functional security requirements needed to counter such attacks. Also, by differentiating preventable from purely detectable attacks, we are able to reference back the safe states of the system which become relevant when prevention is not possible. For future work, we intend to apply this approach to more automotive use cases to determine areas of improvements in which safety and security convergence needs additional attention. Also, one aspect of the safety analysis that intend to leverage is the ASIL level of the safety goals used in the analysis which may be beneficial in determining the security level needed when defining security countermeasures.

6.

REFERENCES

[1] Healing Vulnerabilities to Enhance Software Security and Safety. [2] S. Burton, J. Likkei, P. Vembar, and M. Wolf. Automotive functional safety= safety+ security. In Proceedings of the First International Conference on Security of Internet of Things, pages 150–159. ACM, 2012. [3] I. Iso. 26262: Road vehicles-functional safety. International Standard ISO/FDIS, 26262, 2011. [4] T. Karthik, A. Brown, S. Awwad, D. McCoy, R. Bielawski, C. Mott, S. Lauzon, A. Weimerskirch, and J. Cappos. Uptane: Securing software updates for automobiles. [5] G. Macher, E. Armengaud, E. Brenner, and C. Kreiner. A review of threat analysis and risk assessment methods in the automotive context. In International Conference on Computer Safety, Reliability, and Security, pages 130–141. Springer, 2016. [6] C. Miller and C. Valasek. Remote exploitation of an unaltered passenger vehicle. Black Hat USA, 2015, 2015. [7] D. K. Nilsson, U. E. Larson, and E. Jonsson. Creating a secure infrastructure for wireless diagnostics and software updates in vehicles. In International Conference on Computer Safety, Reliability, and Security, pages 207–220. Springer, 2008. [8] A. Ruddle, D. Ward, B. Weyl, S. Idrees, Y. Roudier, M. Friedewald, T. Leimbach, A. Fuchs, S. G¨ urgens, O. Henniger, et al. Deliverable d2. 3: Security requirements for automotive on-board networks based on dark-side scenarios. tech. rep., EVITA, 2009. [9] SAE. Sae j3061, cybersecurity guidebook for cyber-physical vehicle systems. SAE, 3061, 2016. [10] A. Shostack. Experiences threat modeling at microsoft. In Modeling Security Workshop. Dept. of

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Computing, Lancaster University, UK, 2008. [11] C. Smith. Car hackers handbook. No Starch Press, 2016. [12] T. Zhang, H. Antunes, and S. Aggarwal. Defending connected vehicles against malware: Challenges and a solution framework. IEEE Internet of Things Journal, 1(1):10–21, 2014.

ISBN: 1-60132-455-3, CSREA Press ©

13

14

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Modeling scheduling policy with Constraint Satisfaction Problem approach Hyuk Lee1 , Jin-Young Choi2 1 Department of Computer Science, Korea University, Seoul, Korea 2 Graduate School of Information Security, Korea University, Seoul, Korea Abstract— Many safety critical systems are real-time systems and a failure on the real-time property may cause serious damage on people and environment. Schedulability analysis is a good way of predicting system behavior and it is important for hard real-time tasks in which keeping deadline is critical. In this paper, we have proposed schedulability analysis with constraint solving approach. The behaviors of the scheduler are analyzed and decomposed into state-based behaviors in order to encode them into constraints. Then, constraints for task model are solved by SMT solver for satisfying interpretations. Treating schedulability analysis as a constraint satisfaction problem has some benefits. Constraints are focused on problems itself and it is based on logic formulas which are simple and clear. More importantly, modern SMT solvers can solve constraints in no time.

lem, Satisfiability modulo theories

focuses on satisfiability of task model on certain scheduling discipline. Various SMT solvers are available, CVC4[16], MathSAT5[17], raSAT[18], SMTInterpol[19], Yices[20], Z3[21]. We used Z3py for scheduling analysis which is Python front-end of SMT solver Z3. Python offers a simple and easy environment for beginners to use. In this paper, we have proposed schedulability analysis with constraint solving approach. Once the scheduling algorithm is encoded as constraints, SMT solver can solve satisfiability of task model. The remainder of this paper is organized as follows. Additional information on schedulability analysis and constraints satisfaction problem for our approach is explained in Section 2. In Section 3, scheduler behavior is analyzed and decomposed and encoded as constraints. Section 4 demonstrates schedulability analysis result of example task models. The paper is concluded with Section 5.

1. Introduction

2. System Model and Background

Real-time systems are used in various places with different purposes. They are used from general purpose multimedia system to safety critical systems such as nuclear, automotive, missile and air traffic control system. Among safety critical systems, that require real-time property are mainly hard realtime systems which requires absolute guarantee to meet the deadline. Fail to meet the deadline in the real-time system means failure of the system, and failure of safety critical system can cause damage to people. In order to keep the real-time property well, the prediction of the behavior of a system is very important and it can be achieved through the schedulability analysis. Since the pioneering work by Liu and Layland[1], many kinds of research on schedulability analysis have been conducted with various methods[2], [3], [4], [5], [6]. There also have been many approaches to schedulability analysis with formal techniques. Some of the research have been done with process algebra[7], [8], [9], [10], state machine[11], [12], constraint solving approach[13], [14], [15]. Cheng and Zhang[14], [15] have proposed scheduling overloaded tasks with an SMT-based approach. However, in a hard real-time system which is our target, tasks are not supposed to be overloaded. Our proposed approach

Most real-time systems employ preemptive priority-based scheduling algorithms in which task with a higher priority can preempt one with a lower priority task. Prioritybased scheduling algorithms are further categorized as fixed priority and dynamic priority algorithm depends on the flexibility of the priority assignment. Priority in dynamic priority scheduling may vary at run-time, whereas fixed priority scheduling doesn’t. Rate Monotonic[1] and Deadline Monotonic[22] algorithm are well known fixed priority scheduling algorithm. As for the dynamic priority scheduling algorithm, Earliest Deadline First[1] and Least Laxity First[23] algorithm are widely used. Among those various scheduling algorithms, EDF and LLF are considered as optimal algorithms on preemptive uniprocessor environment since the utilization is maximal. Constraint solving approach, used in this paper, is methods of solving problems in Constraint Satisfaction Problem. CSP is a mathematical problem that is defined as a collection of objects with states that must satisfy various constraints[24]. Properties of the problem are expressed as similar constraints, as a set of finite constraints on the variables, and solve them in the way of constraint problem. The constraints specify the allowable values for the variables

Keywords: Schedulability analysis, Constraint Satiafaction Prob-

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Assumptions on tasks are as follows: • All tasks are periodic tasks • All tasks have the worst computation time • All tasks arrive at the same time • All tasks are independent tasks, no shared resources • All overheads such as context switch are ignored

Table 1: Symbols and Definitions Symbol

Definition

T t ci di oi pi τi πi,t si,t

set of tasks, T = {τ1 , τ2 , · · · , τn } time instant, t ∈ N computation time of task i deadline of task i offset of task i period of task i index of task, τi ∈ T priority of task i at time t, π ∈ Z executed time of task i at time t

scheduled offset oi

task τi

computation time ci

Time arrival

deadline di period pi

Fig. 1: Periodic task τi

in that domain, and the solution to the problem is to assign a value satisfying all constraints to each variable. Constraints of the problem are then passed into the SMT solver which designed to solve SMT problems. Satisfiability Modulo Theories (SMT) problem is: If a formula to be satisfiable, then there exist an interpretation that makes formula true. SAT or boolean satisfiability problem is a type of satisfiability problem expressed in boolean formulas. Since SAT is based on propositional logic, the expressiveness of logic has limitations. SMT is based on first-order logic with extended theories such as real numbers, the theory of integers, and the theories of various data structures such as lists, arrays, bit vectors. SMT can be thought of as a form of the constraint satisfaction problem and thus a certain formalized approach to constraint programming[25]. Once our schedulability problem is encoded as constraint satisfaction problem, SMT solver can find a satisfying interpretation of those constrained variables.

3. Modeling constraint based scheduler 3.1 System and Definitions A real-time system can be defined by the characteristics of tasks. There is a system with a set of tasks T , and worst case computation time of task τi is ci . The system is a realtime system if there exists at least one task τi which belongs to following categories[26]. • • •

Hard real-time task. Task τi must complete its computation ci before deadline di Soft real-time task. Task τi completes its computation ci later than deadline di , Task τi gets penalty Firm real-time task. Task τi completes its computation ci before deadline di , Task τi gets reward

The simplified behavior of scheduling process by a scheduler is described in Algorithm 1. The scheduler takes input task model and proceeds to schedule. It is divided into two cases within the period. • Computation time is completed – Time left until next period → IDLE – Time reached next period → RESET • Computation time is remaining – Time left until next period ∗ Priority is the highest → EXECUTE ∗ Priority is not the highest → IDLE – Time reached next period → DEADLINE MISS The behavior of the scheduler can be further subdivided into categories of constraints. • Scheduler behavior Constraints – Only one task can be executed at one time instant ∗ if τi is executed at time instant t, then τj cannot be executed, where (i 6= j) – A task is executed between its offset and deadline. ∗ if τi to be executed, time t must be oi ≤ t ≤ di • Task behavior Constraints – When a task is executed, computation time is updated ∗ if τi is executed at time t, then si,t+1 = si,t + 1 – If a task is being executed, other tasks should idle for next turn ∗ if τj is idle at time t, then sj,t+1 = sj,t – When the period of a task is reached, the execution time is initialized ∗ if time t = pi , then si,t = 0 • Scheduling policy Constraints – The task with the highest priority is executed ∗ if τi to be executed at time instant t, then πi,t ≥ πj,t , where (i 6= j) – Assign priority according to the policy ∗ if EDF is used, calculate priority πi,t = dmax − (di − t) ∗ if LLF is used, calculate priority πi,t = dmax − (di − t) − (ci − si,t ) ∗ dmax = 1 + max(di ), where i = (1, · · · , n) • Schedulability Constraints – Computation time must be executed before deadline ∗ if time t = di , then si,t = ci

ISBN: 1-60132-455-3, CSREA Press ©

15

16

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Algorithm 1 SMT_Schedule(T ) Input : Set of tasks T Output : Satisfiability of INPUT (Schedulability of T ) LCM(p): Least common multiple of p1..n MAX(πt ): Maximum priority value at time instant t for each τi ∈ T do while (t < LCM(p)) do if (si,t = ci ∧ t = pi ) then Reset for next period else if (si,t = ci ∧ t < pi ) then IDLE for next period else if (si,t < ci ∧ t < di ) then if (πi,t = MAX(πt )) then EXECUTE else IDLE for next turn end if end if end while end for return Satisfiability of T

3.2 Constraints encoding In order to encode the behavior of the scheduler as constraints of state relations, the scheduler is modeled using the behavior constraints defined in the previous chapter. Following pieces of Python code is parts of the program which checks schedulability of the task model. The main part of the program is mostly done with constraints encoding and rest of the program is for processing and parsing the input task model. SMT solver Z3 provides API for Python to import, and solving constraints by simply adding encoded constraints into the solver. Input file of the program is a task model which has tasks information about periods, computation time, deadlines and possibly offsets. All the task information from the task model is stored as constant variables within the program. In the program, a few uninterpreted functions and variables are declared for constraints encoding. Each declaration of uninterpreted function h, x, dp is for execution status, execution time, priority status respectively. Function h takes two arguments of type Proc and Int, returns Exe type value. Function x and dp also take two arguments of type Proc and Int, return Int type value. Variables i, a, b are Z3 generated variables with Int, Proc, Proc type and they works inside of the solver. Rest of variables j, k, maxt, TN are Python variables. Variables j, k are used in manipulating index for loops and lists and TN represents the total number of tasks in the input task model and maxt represents the least common multiple of the period of tasks in the input task model. In the Listing 2 and 6, Python list variable p, d are used to represent period, deadline of the input task model, while t is Proc type Z3 variable for the task. To clarify the code below, some of the symbols defined

previously used differently here, because of some redundancy issues. Some of the symbols from Table 1 maps as follows. Symbol for task τ used as t[], time instant t as i, priority of task π as dp(), executed time s as x(), computation time c as e[]. a) Scheduler behavior constraints: The scheduler selects a task to be executed according to the scheduling policy. In the case of EDF and LLF policy, a task with the highest priority is selected. Once the task is selected, only the selected task must be executed and other tasks idle for their next turn. Atomic execution of a task can be encoded as Listing 1 below. h(a, i) will return the execution status of a at time instant i. Proc type variable a represents a selected task and non-selected tasks are represented as b. Listing 1: Constraint for atomic execution ForAll([i], Implies(And(i>=0, i= 0, i = dp(b, i)))))

Period

Computation

Deadline

Offset

Task 1

3

1

3

1

Task 2

4

2

3

0

Task 3

6

1

5

2

Table 2: Task model H Period

Computation

Deadline

Offset

Task 1

3

2

3

0

Task 2

4

2

4

0

EDF scheduling policy assigns tasks with early deadlines to a higher priority than tasks with late deadlines. Constraint for EDF priority assignment can be encoded as Listing 4 below. dp(t[j], k) will have constrained value that the task with earliest deadline gets higher priority. Listing 4: Constraint for priority assignment (EDF)

4. Evaluation

for j in range(TN): for k in range(maxt): s.add(If(x(t[j],k) < e[j], dp(t[j], k)==maxd−(d[j]−k%p[j]), dp(t[j], k)==0))

Similarly, LLF scheduling policy assigns the highest priority to the task with the least laxity. The remaining computation time is taken into account in the priority calculation. Constraint for LLF priority assignment can be encoded as Listing 5 below. dp(t[j], k) will have constrained value that the task with least laxity gets higher priority. Listing 5: Constraint for priority assignment (LLF) for j in range(TN): for k in range(maxt): s.add(If(x(t[j],k) < e[j], dp(t[j], k)==maxd−(d[j]−k%p[j]−e[j]−x(t[j],k)), dp(t[j], k)==0))

d) Schedulability constraint: A task model is said to be schedulable when all tasks in the task model are able to meet their deadline for a given time period. Schedulability constraint of a task can be encoded as Listing 6 below. Accumulated execution time of a task must be equal to its computation time before its deadline for every period. However, as the accumulation of execution time happens one time instant after its execution, both time instant at the deadline and one before the deadline is checked here. In order to the task model to be schedulable, this constraint must hold for all the tasks in the task model for all given time period. Listing 6: Constraint for schedulability for j in range(TN): for k in range(maxt): if k%p[j]==d[j]−1: s.add(Or(And(x(t[j],k)==e[j], h(t[j],k)==FALSE), And(x(t[j],k)==e[j]−1, h(t[j],k)==TRUE)))

17

Table 3: Task model L

The evaluation of SMT scheduler model has done with two task models, model H and model L as shown in Table 2 and 3. In fact, model H is schedulable, but Model L is not schedulable because utilization exceeds 100 percent. In model H, tasks have computation time of 1, 2, 1 and period of 3, 4, 6 and deadline of 3, 3, 5 and offset of 1, 0, 2, respectively. Also, the least common multiple of all task’s period is 12, which indicates that if the tasks are schedulable up to this point of time instant, they are guaranteed to be schedulable. In Fig. 2 and Fig. 3, task execution is represented as shading boxes. Solid lines, dotted lines, and dashed area represent the period, deadline and offset respectively. The evaluation result of SMT scheduler with model H and model L is shown in Fig. 2 and Fig. 3. The timing graph (a) in Fig. 2 represents an anticipated result of EDF scheduling of model H. Actual scheduling result by SMT scheduler model came as the timing graph (b). The timing graph (a) and (b) in Fig. 2 schduled as follows. At time instant i = 0, Task 2 is executed first since other two tasks are not available because of their offsets. At time instant i = 1, Task 1 and Task 2 competes for their execution turn. In this case, both of Task 1 and 2 have the same relative deadline and would result in the non-deterministic choice of a task. As a result of the non-deterministic choice, Task 1 was selected at time instant i = 1 and completes its first period. Task 2 is executed at time instant i = 2 after competing with Task 3 since Task 2 has an earlier deadline than Task 3, and completes its first period. At time instant i = 3, Task 3 is executed since there are no other tasks to compete for execution. Scheduler schedules in this manner until time instant i = 12. At time instant i = 12, all tasks have completed their computation time for every period successfully. Hence the timing graph (a) has shown that the task model H is schedulable under EDF scheduling algorithm and graph (b) tells us that SMT scheduler works just as we anticipated. The timing graph (c) in Fig. 2 represents an anticipated

ISBN: 1-60132-455-3, CSREA Press ©

18

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

Task 1

Task 1

Task 2

Task 2

Task 3

Task 3 0

1

2

3

4

5

6

7

8

9

10

11

12

0

1

(a) Assumming timing graph of Model H

2

3

4

5

6

7

Task 1

Task 2

Task 2 2

3

4

5

6

7

8

9

10

10

11

12

11

12

11

12

Unsatisfiable

Task 1

1

9

(b) Resulting timing graph of Model H

miss

0

8

11

12

0

1

(c) Assumming timing graph of Model L

2

3

4

5

6

7

8

9

10

(d) Resulting timing graph of Model L

Fig. 2: EDF scheduling of task models

Task 1

Task 1

Task 2

Task 2

Task 3

Task 3 0

1

2

3

4

5

6

7

8

9

10

11

12

(a) Assumming timing graph of Model H

0

1

2

3

4

5

6

7

8

9

10

(b) Resulting timing graph of Model H

Fig. 3: LLF scheduling of task models

result of EDF scheduling of model L. Actual scheduling result by SMT scheduler model came as the timing graph (d). In model L, the deadlines and periods of all tasks are the same. At time instant i = 0 and i = 1, Task 1 is executed and completed its first period since the deadline of Task 1 is ahead of the deadline of Task 2. Task 2 is then executed at time instant i = 2 without competing with other tasks. At time instant i = 3, Task 2 with an earlier deadline is executed. Task 1 fails to complete the computation time and reaches the deadline (end of period) at time instant i = 9. SMT scheduling result of task model L was unsatisfiable. This means that SMT scheduler was not able to find the solution that satisfies the constraints for a given time period (i ≤ 12). The timing graph (d) only shows scheduled tasks of model L up to time instant i = 8, the point where constraints were satisfiable. Since one of our constraint

for schedulability was that the computation time should be completed within the deadline, the constraints were only satisfied for a partial time period. However, it is insufficient bound in order to guarantee schedulability of task model L. As for the LLF scheduling policy, it is similar to the EDF scheduling policy. LLF scheduling policy assigns the highest priority to the most urgent task based on deadline and execution time. As described in Listing 4 and Listing 5 in the previous section, LLF scheduling policy can be implemented by simply replacing constraints on scheduling policy. The timing graph (a) in Fig. 3 represents an anticipated result and timing graph (b) by SMT scheduler model of LLF scheduling of model H. Coincidentally, the result of the LLF scheduling happens to be the same as the result of EDF scheduling policy. However, actual scheduling result came out differently which caused by non-deterministic choice.

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

5. Conclusions and future work In this paper, We have described the constraint solving approach of schedulability analysis. Scheduler behavior is decomposed into smaller state-based behaviors in order to encode them into constraints. Then, our constraint based schedulability analysis was evaluated with two task models. Treating schedulability analysis as a constraint satisfaction problem has some benefits. Constraints are focused on the problem itself and it is based on logic formula which is simple and clear. More importantly, modern SMT solvers can solve constraints very quickly. Constraint solving can be very powerful on describing problem. If a problem is encoded exactly as intended, it will give the exact result. However, few minor mistakes on constraints can give out an awful result which, however, perfectly satisfies encoded constraints. For our future work, we intent to work on hierarchical system scheduling. It will be challenging since hierarchical system can be very complex in constraint point of view.

Acknowledgement This research was supported by the MSIP(Ministry of Science, ICT and Future Planning), Korea, under the ITRC(Information Technology Research Center) support program (IITP-2017-2015-0-00445) supervised by the IITP(Institute for Information & communications Technology Promotion)

References [1] C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming in a hard-real-time environment,” Journal of the ACM (JACM), vol. 20, no. 1, pp. 46–61, 1973. [2] K. Jeffay, D. F. Stanat, and C. U. Martel, “On non-preemptive scheduling of period and sporadic tasks,” in Real-Time Systems Symposium, 1991. Proceedings., Twelfth, pp. 129–139, IEEE, 1991. [3] K. Tindell and J. Clark, “Holistic schedulability analysis for distributed hard real-time systems,” Microprocessing and microprogramming, vol. 40, no. 2-3, pp. 117–134, 1994. [4] J. C. Palencia and M. G. Harbour, “Schedulability analysis for tasks with static and dynamic offsets,” in Real-Time Systems Symposium, 1998. Proceedings. The 19th IEEE, pp. 26–37, IEEE, 1998. [5] J. P. Gutiérrez, J. G. García, and M. G. Harbour, “On the schedulability analysis for distributed hard real-time systems,” in Real-Time Systems, 1997. Proceedings., Ninth Euromicro Workshop on, pp. 136–143, IEEE, 1997. [6] R. I. Davis, A. Burns, R. J. Bril, and J. J. Lukkien, “Controller area network (can) schedulability analysis: Refuted, revisited and revised,” Real-Time Systems, vol. 35, no. 3, pp. 239–272, 2007. [7] J.-Y. Choi, I. Lee, and H.-L. Xie, “The specification and schedulability analysis of real-time systems using acsr,” in Real-Time Systems Symposium, 1995. Proceedings., 16th IEEE, pp. 266–275, IEEE, 1995. [8] H.-H. Kwak, I. Lee, A. Philippou, J.-Y. Choi, and O. Sokolsky, “Symbolic schedulability analysis of real-time systems,” in Real-Time Systems Symposium, 1998. Proceedings., The 19th IEEE, pp. 409–418, IEEE, 1998. [9] H. Ben-Abdallah, J.-Y. Choi, D. Clarke, Y. S. Kim, I. Lee, and H.-L. Xie, “A process algebraic approach to the schedulability analysis of real-time systems,” Real-Time Systems, vol. 15, no. 3, pp. 189–219, 1998.

[10] A. N. Fredette and R. Cleaveland, “Rtsl: a language for real-time schedulability analysis,” in Real-Time Systems Symposium, 1993., Proceedings., pp. 274–283, IEEE, 1993. [11] S.-J. Kim and J.-Y. Choi, “Formal modeling for a real-time scheduler and schedulability analysis,” in International Conference on Parallel Computing Technologies, pp. 253–258, Springer, 2003. [12] N. Guan, Z. Gu, Q. Deng, S. Gao, and G. Yu, “Exact schedulability analysis for static-priority global multiprocessor scheduling using model-checking,” in IFIP International Workshop on Software Technolgies for Embedded and Ubiquitous Systems, pp. 263–272, Springer, 2007. [13] A. Pedro, D. Pereira, L. M. Pinho, and J. Sousa Pinto, “Smt-based schedulability analysis using rmtl-r,” in IEEE Real-Time Systems Symposium, 2016. [14] Z. Cheng, H. Zhang, Y. Tan, and Y. Lim, “Scheduling overload for real-time systems using smt solver,” in Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD), 2016 17th IEEE/ACIS International Conference on, pp. 189– 194, IEEE, 2016. [15] Z. Cheng, H. Zhang, Y. Tan, and Y. Lim, “Smt-based scheduling for multiprocessor real-time systems,” in Computer and Information Science (ICIS), 2016 IEEE/ACIS 15th International Conference on, pp. 1–7, IEEE, 2016. [16] C. Barrett, C. Conway, M. Deters, L. Hadarean, D. Jovanovi´c, T. King, A. Reynolds, and C. Tinelli, “Cvc4,” in Computer aided verification, pp. 171–177, Springer, 2011. [17] A. Cimatti, A. Griggio, B. J. Schaafsma, and R. Sebastiani, “The mathsat5 smt solver,” in International Conference on Tools and Algorithms for the Construction and Analysis of Systems, pp. 93–107, Springer, 2013. [18] V. X. Tung, T. Van Khanh, and M. Ogawa, “rasat: an smt solver for polynomial constraints,” in International Joint Conference on Automated Reasoning, pp. 228–237, Springer, 2016. [19] J. Christ, J. Hoenicke, and A. Nutz, “Smtinterpol: An interpolating smt solver,” in International SPIN Workshop on Model Checking of Software, pp. 248–254, Springer, 2012. [20] B. Dutertre and L. De Moura, “The yices smt solver,” Tool paper at http://yices. csl. sri. com/tool-paper. pdf, vol. 2, no. 2, pp. 1–2, 2006. [21] L. De Moura and N. Bjørner, “Z3: An efficient smt solver,” in International conference on Tools and Algorithms for the Construction and Analysis of Systems, pp. 337–340, Springer, 2008. [22] J. Y.-T. Leung and J. Whitehead, “On the complexity of fixed-priority scheduling of periodic, real-time tasks,” Performance evaluation, vol. 2, no. 4, pp. 237–250, 1982. [23] A. K. Mok, “Fundamental design problems of distributed systems for the hard-real-time environment,” 1983. [24] S. J. Russell, P. Norvig, J. F. Canny, J. M. Malik, and D. D. Edwards, Artificial intelligence: a modern approach, vol. 2. Prentice hall Upper Saddle River, 2003. [25] C. W. Barrett, R. Sebastiani, S. A. Seshia, and C. Tinelli, “Satisfiability modulo theories.,” Handbook of satisfiability, vol. 185, pp. 825–885, 2009. [26] A. Mohammadi and S. G. Akl, “Scheduling algorithms for real-time systems,” School of Computing Queens University, Tech. Rep, 2005.

ISBN: 1-60132-455-3, CSREA Press ©

19

20

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

ISBN: 1-60132-455-3, CSREA Press ©

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

SESSION CYBER-PHYSICAL SYSTEMS AND APPLICATIONS Chair(s) TBA

ISBN: 1-60132-455-3, CSREA Press ©

21

22

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

ISBN: 1-60132-455-3, CSREA Press ©

23

INSIDabcdef_:MS_0001MS_0001

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 | INSIDabcdef_:MS_0001MS_0001

Shortest Job First Scheduling for Reducing Jitter in Cyber Physical Systems JiYoung Heo and Moonju Park Department of Computer Science and Engineering, Incheon National University, Incheon, Korea

Abstract – This paper considers the problem of minimizing jitters in Cyber-physical systems with multiple controller tasks. Unlike previous approaches, we adopt non-real-time scheduling method which provides shorter latency - Shortest Job First (SJF) scheduling. We show that the SJF scheduler reduces average response time jitter, and provide a condition that can be used for guaranteeing hard deadline in designing real-time control systems. Simulation results show that the SJF contributes to the stability of the system by reducing jitters.

desirable property for control applications, and provide a way to guarantee for meeting the hard deadline requirement. The rest of this paper is organized as follows. Section 2 describes the system model and explains the jitter problem in real-time scheduling on control systems. Section 3 shows how the Shortest Job First scheduling can be used to control the jitters. In Section 4, we present simulation results that show the control performance of the SJF. Section 5 concludes our work.

Keywords: Cyber physical system, real-time scheduling, jitter

2

1

2.1

Introduction

On Cyber-physical system (CPS), the physical environment is affected by embedded systems integrated with controller tasks which replaces old-day analog devices. For cost reduction and efficiency, a CPS nowadays often consists of multiple controller tasks. Multiple tasks on a uniprocessor system causes scheduling problems; delays and jitters introduced by interference among tasks, which may degrade control performance and even make the whole system unstable [1,2]. The jitter problem in real-time control system has been studied for both fixed-priority and dynamic-priority scheduling [3,4,5,6,7,8], or aperiodic scheduling methods [9,10]. In [4], Cervin et al. developed a method to find a bound of the inputoutput jitter in Earliest Deadline First (EDF) scheduling and introduced the concept of jitter margin, which is a condition of jitter for stability. Many studied assigning shorter deadlines to reduce jitter in real-time systems earlier [11,12], and the idea of combining deadline assignment shorter than a period and jitter margin for control performance has been studied mostly using the EDF scheduling algorithm [5,6,7]. Previous works have focused on how the real-time scheduling theory can be integrated with control systems, while maintaining the guarantee to meet hard real-time requirements. The scheduling policies consider real-time scheduling first, then it tries to achieve control performance with best effort. In this work, we take the opposite approach; we focus on minimizing jitter which directly affects the control performance, then provides a guarantee for real-time requirements. To this end, we suggest to use traditional Shortest Job First (or, Shortest Remaining Processing Time) scheduling. We will show that the SJF (or, SRPT) has very

System model and jitter problem Task model and real-time scheduling

We consider the target system as a preemptive hard realtime system with a single processor. In real-time systems, the correctness of the result is determined by when the result is delivered, which is called “deadline”. A periodic task set = { , , ⋯ , } consists of independent periodic tasks. A periodic task is characterized by ( , ), where represents the period and represents the worst case execution time. The deadline of a task released is equal to its period; that is, the task should finish its job at his period before its next period begins. In each period a task has a job that must finish before + when the job is requested at . We assume that ≥ . Without loss of generality, we can assume that the task set is sorted in nondecreasing order of periods; that is, if > then ≥ . When an instance of is invoked at time t and finishes at time , − is the “response time” of the instance. The worst case response time (WCRT) of is defined as the maximum possible response time among all execution instances of . A task is schedulable if and only if the WCRT of the task is less than or equal to by some scheduling algorithm. A task set is said to be schedulable if and only if all the tasks in the task set is schedulable by a scheduling algorithm. We assume that sampling delays in the control system are negligible. Such delay that may cause jitters in input delay can be minimized by periodically sampling at the A/D converter in the real system. The utilization of

ISBN: 1-60132-455-3, CSREA Press ©

is defined as

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 |

INSIDabcdef_:MS_0001MS_0001

24 INSIDabcdef_:MS_0001MS_0001

= The total utilization of a task set

/ .

(1)

is defined as

( )=∑

.

(2)

It is assumed that the tasks are independent of each other so there is no shared resource among them. There are two kinds of priority assignment scheme in real-time scheduling. Fixed priority schedulers assign a priority to each task once and for all, and a task with a higher priority can preempt any lower priority task. In dynamic priority scheduling, the priorities of tasks are assigned at runtime. While Rate Monotonic (RM) scheduling is optimal among fixed priority schedulers for preemptive tasks [13], the Earliest Deadline First (EDF) is optimal for dynamic priority scheduling for both preemptive [13] and non-preemptive scheduling [14] on uniprocessor. For preemptive tasks, it has been shown that EDF can schedule real-time tasks with total utilization up to 100%, and for RM scheduling 69% has been used as a utilization bound, that is a sufficient condition for the schedulability based on the results of [13]. However, it has been shown that determining whether a non-preemptive task set is schedulable is NP-hard [14].

2.2

Scheduling algorithms and jitter

The maximum variation in the time of the occurrence of a certain event of a task in the system is called jitter of the event. In [5], 3 different types of jitters are defined which are particularly interested in control applications: the input jitter, the input-output jitter, and the response time jitter. These jitters are defined as the maximum variance of time in (1) input latency (INL) which is a delay before actual execution, (2) input-output latency (IOL) which is the time duration between the start and completion time of execution, and (3) the response time which is equivalent to the sum of the former two latencies. Fig. 1 shows the time used for jitter definition where boxes runs. indicate the task

Fig. 2 shows an example of task scheduling according to EDF (downward arrows indicate the deadline). In this example, we consider three real-time tasks specified as: = (4,2), = (5,1), = (10,2). The total utilization of the task set is 95%, so this task set is schedulable by EDF if the tasks are preemptible. The tasks will repeat the schedule shown in Fig. 2 because their least common multiple of periods is 20. From Fig. 2, we can calculate the jitters of tasks as follows: (1) RTJ: for

2-2=0, for

(2) INJ: for

0, for

(3) IOJ: for

2-2=0, for

3-1=2, for

2-0=2, for

7-5=2. (Average 4/3)

3-1=2. (Average 4/3)

1-1=0, for

4-4=0. (Average 0)

Fig. 2. EDF scheduling example

Fig. 3. RM scheduling example

Fig. 1. Timing diagram of the control task For these three latencies, three kinds of jitters are defined as: (1) input jitter (INJ), (2) input-output jitter (IOJ), and (3) response time jitter (RTJ). If we know the constant part of the delay in a control system and the jitter of a control task, the stability of the closed-loop system is guaranteed if the jitter is bounded by the jitter margin of the delay [4]. Therefore, minimizing the jitter directly affects the control performance and the stability [6].

Fig. 4. SJF scheduling example Fig. 3 shows RM scheduling of the example task set. The task set is also successfully schedulable by preemptive RM. The jitters of tasks are as follows:

ISBN: 1-60132-455-3, CSREA Press ©

25

INSIDabcdef_:MS_0001MS_0001

Int'l Conf. Embedded Systems, Cyber-physical Systems, & Applications | ESCS'17 | INSIDabcdef_:MS_0001MS_0001

(1) RTJ: for

2-2=0, for

(2) INJ: for

0, for

(3) IOJ: for

2-2=0, for

3-1=2, for

2-0=2, for

8-5=3. (Average 5/3)

3-1=2. (Average 4/3)

1-1=0, for

5-4=1. (Average 1/3)

In this example, the jitters of RM scheduling are on the average longer than those of EDF scheduling. In general, the EDF reduces the jitter of tasks with long period significantly by increasing the jitter of tasks with shorter deadline slightly [5]. But we cannot say which algorithm is better than other ones in terms of jitter yet. For comparison, Fig. 4 shows scheduling by the Shortest Job First (SJF). The SJF assigns higher priority to the task with shorter remaining execution time. If we favor task 1 over task 3 when the tasks have the same priority, the task set is schedulable by SJF (note that at time 4 and 12, task 3 is not preempted by task 1 because the remaining execution time of task 3 is shorter than task 1) and we have the following jitters: (1) RTJ: for

4-2=2, for

1-1=0, for

(2) INJ: for

2-0=2, for

0, for

(3) IOJ: for

2-2=0, for

1-1=0, for

5-3=2. (Average 4/3)

3-1=2. (Average 4/3) 2-2=0. (Average 0)

In this example, the average jitters of the SJF are the same as the EDF. But SJF has no guarantee for the real-time task to meet their deadlines. However, it has been known that the SJF is optimal in minimizing the average waiting time. We will now consider using this property of the SJF in real-time control systems.

3

Shortest Job First scheduling for jitter control

It has been shown that shortest job first (or, the shortest remaining processing time first) scheduling algorithm is optimal for minimizing the average response time [15] very early. But the SJF is not considered to be practical, because the execution time of tasks is not known in advance [16]. The optimal property of the SJF can be stated as in the following theorem. Theorem 1. The average completion time of a task set is minimized by SJF scheduling. Proof. See [15].

■

Furthermore, based on Theorem 1, we can see that the SJF scheduling minimizes the average response time jitter of realtime control tasks. Theorem 2. The average response time jitter is minimized by SJF scheduling.

Proof. We prove the theorem by contradiction. Let us assume that there is a task set whose average response time is not minimum with the SJF. Let be the latest completion time and be the fastest completion time of when tasks are scheduled by an algorithm S. Then RTJ of scheduled by S is given by − . By the assumption, we have ∑

∈

(

)