Real Time Embedded Systems

Coventry University- Faculty of Engineering and ComputingM25CDE (Real-Time and Embedded systems) 2013
M25CDE Coursework Real-Time Application

FADEC - Full Authority Digital Engine Control System
By: Gilles Rubens Badouet (Student ID: 3940347) Module Leader: Dr. Norlaily Yaacob
Gilles Rubens Badouet
- MSc Network Computing Course -
Coventry University 2013
List of contents
1. Part 1 Full Authority Digital Engine Control................................................................................. 2 1.1. Introduction and description of the system .................................................................................. 4 1.2. FADEC operating scenario and Data Flow Diagram (DFD) ....................................................... 6 1.2.1. FADEC operating scenario ................................................................................................... 6 1.2.2. FADEC Data Flow Diagram (DFD) ..................................................................................... 8 2. Part 2 Communication and Synchronisation issues within real-time and embedded systems 12 2.1. Real-Time Embedded Systems overview .................................................................................. 12 2.2. Semaphore synchronisation mechanism .................................................................................... 13 2.3. Real Time Operating System (RTOS) ....................................................................................... 16 2.3.1. Definition and major role .................................................................................................... 16 2.3.2. Facilities/roles and RTOS requirements ............................................................................. 17 2.3.3. RTOS examples .................................................................................................................. 19 3. Part 3 Implementation of real-time application ........................................................................... 23 3.1. Development details................................................................................................................... 24 3.2. Application description .............................................................................................................. 25 3.2. Application code lines with descriptions ................................................................................... 26 3.3. Program outputs ......................................................................................................................... 31 Summary.............................................................................................................................................. 34 List of references ................................................................................................................................. 35
List of figures and tables

Figure 1: FADEC on an aircraft engine.4 Figure 2: Sample of a FADEC control chain.....6 Figure 3: DFD of FADEC system....11 Figure 4: Semaphore operations with threads..14 Figure 5: Threads states16 Figure 6: LynxOS logical and simplified architecture.....20 Figure 7: Integrity logical and simplified architecture.....21 Figure 8: Logical architecture of RTLinux..22 Figure 9: Application outputs for 10 seconds run....32
Table 1: Comparison between Semaphore and other major mechanisms15 Table 2: RTOS requirements....19
1. Part 1 Full Authority Digital Engine Control

1.1. Introduction and description of the system
The evolution of aircraft gas turbine engines has led to ever increasing demands on engine control systems to increase thrust and improve fuel consumption resulting in a wide use of digital electronic control systems. The earlier generations of such systems, which used the supervisory concept, were introduced in the 1970s and can be found in a number of aircrafts in operation today. However, the supervisory concept has been showing some limitations regarding the requirements of the most modern engines. This led in the 1980s to the Full Authority Digital Electronic Control (FADEC) system. The FADEC is an electronic and computational total system allowing the control of an aircraft engine (University of Gothenburg's LMS, n.d). FADEC device
Figure 1: FADEC on an aircraft engine (Safran Sagem, 2013) The main functions of the FADEC system: Control and regulation of the fuel pump, providing to the turbine engine the necessary amount of fuel for safe controlled operation. Measurement of the exhaust gas temperature Measurement of the relative position of the throttle stick and the air pressure in the combustion chamber. It monitors all of the controls necessary to guarantee that the engine stays between the user defined parameters of operation.
Providing failsafe shutdown of the engine when it has detected any important anomaly. Can record up to 900 hours of flight (for the most modern)
The FADEC main hardware components: Electronic Control Unit (ECU), the core of the control system integrating electronic circuits, ignition coils and microprocessor controllers. The microcontroller or other chips on the PCB (Printed Circuits Board), typically in EPROMs (erasable programmable read only memory) or flash memory so that the CPU (Central Processing Unit) in charge of instructions execution can be re-programmed by uploading updated code or replacing chips. Health Status Annunciator (HSA) consisting of lights on panel to control and provide information about the system components status. Information provided is displayed on a LCD (Liquid Cristal Display) screen. Fuel pressure sensors and many redundant sensors linked to the ECU A thermocouple input A throttle servo input Power connections for the fuel pump and the battery. A digital serial port to program and read the data real-time to a PC. The FADEC main soft components include: EPR (Engine Pressure Resource) system (For Thrust, over Entire Range of Engine Operation Without FADEC Computer Failure) N Schedules (For Thrust as per Pilots Throttle, Engine Operation in case of Limited FADEC Computer Functionality). In case of certain degree of FADEC failure there is an automatic mode switch-over from EPR to N rating. However, if the failure disappears, the pilot can reset the mode to switch-back to EPR mode. Engine controller FADEC Controller The main disadvantages of FADEC system are that its control cannot be overridden by the pilot. Moreover in the event of complete FADEC failure, pilot is left with no other option than having to fly with least performance and very limited time, just sufficient to land safely in the best of cases. This lack of the system control when a failure occurs defines the classification of the FADEC system on the side of hard real time system.
Most part of aircrafts equipped with the FADEC system has more than one engine because with a single-engine, engine, the consequence of a failure in the system is catastrophic since the engine is totally and automatically controlled. With more than than one engine, a failure in one of the engines does not alone lead to a catastrophic situation. The aircraft can still operate with one engine only, although with reduced performance. For some aircrafts equipped with single-engines, engines, very hard constraints are put on the reliability and the fault tolerance of the FADEC system (FADEC Users Manual. V1.3 10/3/99 n.d.).
1.2. FADEC operating scenario and Data Flow Diagram (DFD)

1.2.1. FADEC operating scenario
The FADEC is a very complex system; therefore the working working scenario we will be describing is quite basic and we will focus the scenario description on two phases: From the engine start up till the aircraft in cruise. . First of all, the inputs are received by the electronic engine
controller and analyzed up to 70 times per second. The figure below shows a control chain
that supports the interaction between the FADEC system and the aircraft components.
Figure 2: Sample of a FADEC control chain
- MSc Network Computing Course Cours -
Scenario description Due to the fact that FADEC is a very complex system, only some main steps are taken into account and described. For the take-off, electric signals are sent by the aircraft's thrust lever through the throttle in the cockpit. When the electrical power is turned on, the FADEC controller also turns on with other software components. FADEC controller then measures
Cylinder Head Temperature (CHT) to determine the amount of fuel needed for start and
activates the boost pump to deliver a fuel pressure of approximately 50 psi with an ignition timing of about 5 and store them in their repository. The Engine Controller then gets the fuel pressure and ignition timing values and set them to start the aircraft engine. At takeoff power, the FADEC Controller starts adding fuel to the cylinder system to regulate power and temperatures. At the same time, the HSA (Health Status Annuciator) starts monitoring sensors, cylinders, engine, connectors and other components and keeps displaying simultaneously Green when (all the component are working properly); Yellow (when a minor error occurred and automatically correct the error); Orange ( when more than one error or issue occurred, also automatically fix them). Once at cruise altitude, the FADEC controller starts adding fuel into cylinders up to a suitable quantity. Concurrently, the EPR system starts calibrating cylinders by setting the mixture for each cylinder to approximately 70 F. With more fuel added in the cylinders and cylinders also calibrated, both FADEC Controller and EPR system then start regulating the engine power, generally from 28 to 30 MP (manifold pressure) by first dropping the propeller speed to 2400 RPM (Revolutions per minute). The above modification leads the engine into a stability mode for one or two minutes to allow temperatures to stabilize before getting back to the highly running status once temperatures are stabilized. Note: In critical cases (not taken into account in our scenario), the HSA will display Red and enable a warning alarm meaning that some important components are facing critical issues that have not been yet fixed, and therefore switch over from the normal mode (EPR mode) to critical mode called N- Schedules, when also notify the pilot to get ready for a possible landing in the shortest deadlines if the issues are not fixed in a given time. However, if the failure disappears, the system can reset the mode to switch-back to EPR mode.
1.2.2. FADEC Data Flow Diagram (DFD)
Based on the above scenario description, we can view and understand the interaction between entities and processes and can therefore design the data flow diagram of FADEC system, from the engine start till its running phase. Assumption = 1 FADEC system = 1 Aircraft = 1 Engine = 1 Throttle FADEC components and aircraft components work properly. Minor errors occur and are automatically fixed. > 1 Sensors > 1 Cylinder propeller speed = 2400 RPM at cruise altitude Engine mode = stability mode for 02 minutes, for temperature stabilization FADEC/ Engine mode = EPR (Engine Pressure Resource) mode Green displayed = Perfect working mode for all components Yellow displayed= Good working mode with one minor detected error Orange displayed= Working mode with some detected issues Data output Electrical signals Electrical power status (on or off) System on HSA enable mode Perfect status Minor error Trivial issues Cylinders temperatures values Stabilised- temperatures Calibration value Engine stability mode Engine up -signal
Fuel quantity Updated power value Fuel pressure and ignition timing values Engine power (e.g. 28 30 MP) Propeller updated speed ( e.g. 2400 RPM) Cylinder mixture/calibration value (e.g. 70 F) Engine optimized running mode Reduced speed Processes The throttle in the cockpit sends electric signals to the FADEC system FADEC system controller measures Cylinder Head Temperature FADEC system controller determine the amount of fuel needed for start FADEC system controller activates the boost pump FADEC system controller delivers fuel pressure and ignition timing values Stores pressure and ignition timing values Engine controller get pressure and ignition timing values Engine controller set ignition timing and start engine FADEC controller enables HSA monitoring system HSA monitors engine, sensors, cylinders, connectors and other components HSA displays green HSA displays yellow HAS displays orange System starts adding fuel into the cylinders to regulate engine power Engine Pressure Resource system get calibration value EPR (Engine Pressure Resource) system calibrates cylinder FADEC Controller adds fuel to cylinders FADEC Controller and EPR system start regulating engine power Drops propeller speed (e.g. to 2400 RPM (Revolutions per minute). The engine goes into stability mode for one to two minutes. Stabilise system temperature Engine returns into highly running status Entities
Aircraft throttle
FADEC Controller
Engine Controller Engine Pressure Resource (EPR) System HSA (Health Status Annunciator) Engine File Calibration values registry Fuel pressure and ignition values repository
10
Figure 3: DFD of FADEC system
11
2. Part 2 Communication and Synchronisation issues within real-time and embedded systems
2.1. Real-Time Embedded Systems overview A real-time and embedded system is a computational system in which the processor and the memory are included in a system and the software is dedicated for a specific application or function, subject to the dynamic evolution of an external process connected to it and which it has to control behaviour within a given time. In other words, it is a system in which after an event has occurred, a system or application has to respond to that event within a certain deadline (Laplante, P, A, 2004). Thus the correction of a real-time system does not depend only on the accuracy calculations and processing but also on the time at which the results are provided. There are two types of real time systems: Hard real time characterised by the fact that missing a constraint (mostly deadline) leads to the failure of the system. For example, if a system must perform a task in 1 second absolutely, this can be categorised like hard real time system Soft real time system. Here, the missing of a constraint does not affect the whole system and does not lead to a system failure. For example, if a system should perform a task in about 1 second or more, this is soft real time system (Burns, A. and Wellings, A 2001). Sometimes a system can be defined as a firm real time; it means it is half way hard and hard way soft real time application. Whatever the type of real time and embedded system is, the followings are different characteristics of real time systems: Deadline: determining the period within which a task must be performed, since tasks perform their functions according to prescribed deadlines. Priority, demining the importance of a task, every task in a system has a priority, the more important the task is the higher the priority is. So the higher the priority is, the better the chance of the task to be executed. Pre-emption allowing higher priority task to pause the lower priority task when necessary. Time schedule: Maintain tasks execution order based on priority
Gilles Rubens Badouet - MSc Network Computing Course Coventry University 2013
12
Concurrent control of separate system components: Devices and applications operate concurrently Extremely reliable and safety: Real time and embedded systems control typically the system or the environment in which they operate and failure in control can results in crucial damage and event loss of lives. Non determinism: A real time system must respond to different non- determinism requests from its environment. A real time program never terminates but keeps on serving its environment (Horning, J, 1978). One of the main issues of any concurrent system development such as a real time application is the conception and the realisation of intercommunication within processes. Communication consists of the exchange of data among processes and the synchronization deal with the relation between one process thread and another. In order to ensure concurrency in processes execution and deal with communication and synchronisation issues among processes, there are several synchronisation mechanisms that are used in real-time programming, namely message passing, rendezvous, semaphore, monitors and more. They all control the order in which task should execute (Burns, A. and Wellings, A, 2001). For our application presented in part 1 (FADEC), we will use the semaphore synchronisation mechanism coupled with threads concept in Java.
2.2. Semaphore synchronisation mechanism

Semaphore synchronisation mechanism consists of mutual exclusion programming and condition synchronisation. The goal is to ensure that no many processes access to a shared resource simultaneously that should not normally be accessed concurrently (Burns, A. and Wellings, A, 2001). Semaphores are especially important to manage threads that need to access shared resources. Within concurrent applications programming, the interaction between semaphore operations and threads can be illustrated as shown on the figure below.
13
Figure 4: Semaphore operations with threads (Mbed, 2012) Dijksta (1968), the designer of Semaphores mechanism stated that a semaphore is a nonnegative integer variable that can only be acted through two procedures except the initialization state. Those two operations or procedures are: P(S) - Wait, down: If the value of semaphores S is positive and a process doing P(S) produces the decrement of S via an atomic action, otherwise the process blocks waiting for another procedure called V(S). In concurrent programming, and atomic action is an operation or a set of operations indivisible that must complete without interruption. The syntax structure is: Wait (p) --- proberen, test: wait(s) { while (s == 0) ; s--; } V(S)- Signal, up: If no process is blocked and if one which does a V(S), then the value of S will be decremented, still in an atomic way, otherwise, a process blocked on S will be awakened. The syntax structure is: Signal (v) --- verhogen, increment: Signal (s) { s++; }
14
The table below presents a comparison between Semaphore and some other major synchronisation mechanisms. Semaphore Supported by Java language, C, C++, C#.Net Monitors Supported by Java, Concurrent Euclid, Concurrent Pascal, Emerald, Mesa, Modular & Modula- 2, Turing plus, C, Pascal plus, C#.Net Deal with utual exclusion Deal with mutual over a critical section with a simple condition synchronisation exclusion using facilities called monitors, but with a need of high condition synchronisation Use several methods to deal with mutual exclusion. The major method is the use of processes to regulate shared resources access Deal well with condition synchronisation Does not deal well with condition synchronisation Deal with conditional synchronisation Partially deal with conditional synchronisation Low level primitives, low level object. Semaphores can also be used to implement monitors Internal structure easy read Internal structure difficult to read due to the use of many condition variables Internal structure easy Internal structure easy read read Mixture of High and low level primitives. Monitors are objects accessible through multiple threads High level primitives High level primitives Use a guard (acceptance Boolean precondition and the FIFO (first in first out) method Message passing Supported by Java, Actors, CSP, CONIC, Gypsy, Joyce, Nil, Occam, PLITS, SunOS, C, C#.Net Rendezvous Supported by Ada language, Java, Concurrent C, Lynx, Nil, Occam, C#.Net
Table 1: Comparison between Semaphore and other major mechanisms
The major advantages of using Semaphores for communication and synchronisation issues in our application consist of the fact that they highly simplify protocols when dealing with
15
synchronisation, compared to other synchronisation mechanisms. Then there is no need for busy-wait loops when Semaphores are used. However, we should take care and keep attention to details when using semaphores to implement synchronisation because it is quite hard to make use of semaphores correctly, it is easy to mix up wait() and signal() procedures particularly when it comes to manage errors.
2.3. Real Time Operating System (RTOS)

2.3.1. Definition and major role
An RTOS is a class of operating system designed to control and manage a real-time application; that means supporting systems developments that must guarantee deadlines and correctness of results. Thus an RTOS must follow real time applications criteria (efficiency, predictability and timeless. Major designs of real time operating systems respect memory allocation concept, scheduling, inter task communication and interrupt handlers. The choice of an operating system is important for the design of a real time application, that is, selecting a suitable language and that mostly assign priorities to deal with time response (Cedeo, W and Laplante, A. 2007). Within a real time operating system, a thread can be in the states illustrated by the following digram:
Figure 5: Threads states (Mbed, 2012)
16
RUNNING: The current running thread is in the RUNNING state. At this state, only one thread can be at a given time;
READY: Threads currently ready to run are at READY state. When the thread in RUNNING state has just terminated or is WAITING for the next thread in READY state possessing the highest priority, it becomes the RUNNING thread;
WAITING: Threads that need an occurred oven before execution are in the WAITING state;
INACTIVE: Threads that have not been terminated are in the INACTIVE state. These threads in general do not consume system resources (Mbed, 2012).
2.3.2. Facilities/roles and RTOS requirements
In real time and embedded applications, the kernel of the system often serves as RTOS and therefore has less functionality than commercial and typical RTOS used for wider systems; on the other hand, RTOS are also used to develop real time applications (Baskiyar, S; Meghanathan, N 2004). Whatever the RTOS, the main roles and facilities are following listed. The schedule tasks in real time applications The RTOS schedule operations on a base of priority and is able to interrupt tasks being run according to some specifications. In the FADEC scenario, the RTOS guaranty for example the priority on sensors and cylinders management concerning the system monitoring. Deadlines management within real time applications The RTOS ensures that processes should be completed within a certain specified time without compromising the system. In the FADEC system, when the engine is running and must move from the running status to the stability status, it automatically stays on the stability mode for a certain time (notably 4 minutes maximum for our current case). Allow error recovery when a failure occurs When an error occurs during a process or even a whole operation, the RTOS is designed to recover such an error automatically. This can be demonstrated on the FADEC system when for example, the cylinder try to drop the propeller speed to new wanted value and propeller keeps running with the same speed due to some error in the system. The RTOS facilities will automatically correct the error.
17
Allow the incorporation of external hardware The typical example is the incorporation of the engine and aircraft hardware components to the FADEC application. Some of the hardware components are the aircraft throttle which is an external entity and is also the entity which enable the couple FADEC/engine by sending and electrical signal. Guarantee correctness of results within applications Respecting deadlines management, the RTOS also make sure of the results correctness since it is probably before all the most important aspect of RTOS; it means every operation ideally results in a correct output. This is especially imperative to guarantee for example that the FADEC system controlling the whole aircraft engine should be able to do so by providing correct outputs during all operating the steps of the operating scenario, from the aircraft take-off till its landing. Provide small footprint and overheads The RTOS is designed to limit operations or tasks congestion, and operations are completed following the most efficient way. For example, there is no need to go through many steps to complete a task that can be completed within one step; or using resource when it is not really necessary. Provide low task switching latency An RTOS ensures that the time between tasks execution is minimum and well regulated. To satisfy its roles an RTOS should be able to meet requirements listed and described in the table below. RTOS requirements Predictable synchronisation Description This is important to regulate multiple threads
communication. Within that inter task communication, there should be the ability to block and release resources when necessary. Sufficient Priority Levels To manage well prioritized task scheduling, the RTOS should possess suitable number of levels of priority aiming to guarantee efficient implementation. Predefined latencies The timing of the RTOP must be designed with the respect to the specifications that follow: Interrupt latency (time
18
between the execution of the last instruction of the task interrupted and the first instruction of the interrupt handler); Interrupt dispatch latency (time to switch from the last instruction in the interrupt handler to the next scheduled to run) and Task switching latency (time to save the context of a currently executing task and switch to another). Dynamic deadline identification To complete pre-emption, a RTOS must be able to identify the task with the earliest deadline and dynamically. Besides, the deadline information can be converted to priority levels used for resource allocation. Multi-tasking and pre-emptive This requirement is set to support multiple tasks in real time applications. The system scheduler must have the ability to pre-empt all the tasks in the system and provides resource to the task with the highest priority, that is, to the task that need more the resource.
Table 2: RTOS requirements (Baskiyar, S.; Meghanathan, N. 2004)

2.3.3. RTOS examples
There is a variety of RTOSs that can be commercial or open source, for small or big memory devices, for hard or soft real time applications and more. Being given that the FADEC is a hard real time system, we will provide discussions on some RTOSs that can be used for the FADEC system by also mentioning some facilities that these RTOSs can offer. - LynxOS From LynuxWorks, LynxOS is the most open hard RTOS available today with the native interface of Linux/Unix and POSIX. LynxOS provides multithreaded operating system built for advanced and complex real time applications such as FADEC. The LynxOS kernel has the facility of scheduling, dispatching interrupts and synchronising tasks. It can use FIFO (first in first out), dynamic deadline monotonic scheduling and time-slicing as an example of scheduling policies (Baskiyar, S; Meghanathan, N 2004). The figure below illustrates a simplified architecture of LynxOS.
19
Figure 6: LynxOS logical and simplified architecture (Wikipedia, 2013) Three programming languages (Ada, C, C++ ) are available in LynxOS 5.0 (the latest version) and the supported platforms include: Motorola 68010, Intel 80386, ARM architecture and PowerPC (Wikipedia, 2013). Some facilities provided by LynxOS include: Mission critical performance and reliability, Open APIs Linux ABI compatibility, Full POSIX (Portable Operating System Interface) conformance, Advanced networking features for rapid development of differentiated products, Perform complex series of tasks within specified period of time, Support multiple applications with multiple interrupting devices, Take full advantage of todays powerful high-end microprocessor and advanced networking architectures, Remote access control through console command line (LynuxWorks, 2005). As many other RTOS providing real-time scheduling algorithms, LynxOS has the disadvantage that critical tasks cannot be specified or set and there is therefore no way to prespecify operations susceptible to fail during overloads. Integrity RTOS From Green Hills Software. Inc, Integrity is designed on a base of a partitioning architecture to supply real time and embedded applications with high performance, security, reliability
20
and real time performance. To come up with this, Integrity makes use of hardware memory in order to isolate and protect applications. The following picture shows a simple logical architecture of Integrity.
Figure 7: Integrity logical and simplified architecture (Green Hills Software, 2011) Integrity supports many platforms and among others Intel x86/IA/Atom, IBM Power Architecture, ARM Ltd. ARM, MIPS Technologies , Analog Devices Blackfin, Texas Instruments OMAP, Cavium Networks and more. The Integrity kernel has been built to reduce any overheads within the system and aims to serve the highest priorities interrupts with a minimum of latency (Green Hills Software, 2011). One important deployment of Integrity is its use in the application on part 1, to achieve FAA DO-178B, Level A certification for the sophisticated EMC-100 Full Authority Digital Engine Control (FADEC) system (Green Hills Software, 2013). Apart from its common advantages, Integrity presents many facilities namely: Integrated Project Wizard, Event Analyser, Simulators, Resource Analyser, Integrate Utility, MULTI IDE, Double Check integrated static Analyzer, Time Machine debugging suite,
21
Optimizing compilers, Certified POSIX conformance, Simplified migration (Green Hills Software, 2011). Although Integrity presents a lot of advantages for real time applications, some disadvantages can be raised such as the cost of the solution as one of the biggest disadvantages (the licence is very costly and restrictive) mostly if one want to benefit from many facilities tools. As other RTOS the footprint and overhead issues cannot be solved at hundred percent (Japenga, B, n.d.) RTLinux RTOS Supplied by Finite State Machine Labs Inc, RTLinux is a hard RTOS written in C and supporting the standard POSIX1003.13/PSE51 and provides shared memory synchronisation mechanisms. The RTLinux kernel is run under Linux and is a pre-emptive system. The real time applications operated through RTLinux are managed via real time threads and signal handlers (Finite State Machine Labs Inc, 2001). The figure below summarizes the RTLinux architecture.
Figure 8: Logical architecture of RTLinux ( Linuxforyou, 2010) The platforms supported by RTLinux are x86(SMP and uniprocessor), Power PC, Alpha.RTLinux/Pro and MIPS. RTlinux is also an open source solution that can be
downloaded from anywhere over the internet.
22
The facilities offered by RTLinux are: A debugger is offered from the version 2.3 to prevent errors and system crashing, The x86 and PowerPC platforms provide the CPU supports oating point, Provides C++ APIs, Easily allows programmers to write applications that combine the advantages of a lean, hard RTOS at hardware speeds, Supports real-time interrupts handlers, also real-time periodic tasks with interrupt latency and scheduling jitter close to hardware limits, Offers command line for remote access, Run Linux as its lowest priority thread that provides total access to the full power of the OS through a variety of communication mechanisms (Finite State Machine Labs Inc, 2001). The disadvantage of RTLinux is that it does not support priority inheritance. Furthermore it also has as other RTOS the issues of the footprint and overhead that cannot be solved completely.
23
3. Part 3 Implementation of real-time application

After providing the description of the application, its data flow diagram, the synchronisation and the communication mechanisms by concurrent processes in real time within the application; we will now chose some concurrent processes and implement them through java programming language.
3.1. Development details

Programming language: Java IDE: NetBeans 7.2.1 Output display mode: Console Synchronisation and communication mechanisms: Semaphores and Threads Number of chosen sub-systems: 2 Subsystem 1: Accesses to fuel pressure and ignition values repository Subsystem 2: Concurrent display of FADEC components status by the HSA (Health Status Annuciator) monitoring system. Number of chosen processes: 5 For Subsystem 1: FADEC Controller stores fuel pressure and ignition values in their repository. Engine Controller gets fuel pressure and ignition values in their repository (when the values have been put). For Subsystem 2: HSA displays Green status, stating that all the components are working perfectly HSA displays Yellow status, stating that all the components are working and only a minor error has been detected and is being fixed HSA displays Orange status, stating that some components are facing issues; Issues being fixed.
24
Note: All the 5 processes are occurring concurrently. The parallelism is more observed in the subsystem 2, for components status must be displayed all at the same time. The subsystem 1 is not continuously performing like the subsystem 2 because it consists of a part of FADEC system start only, that is, the engine start; whereas the subsystem 2 keeps performing because it monitors the components (sensors, cylinders, connectors) when they are working throughout the FADEC system operation.
3.2. Application description

The java application consists of 8 classes implementing the 5 processes above: The main class FADEC.java is the communication gateway amongst all the other classes and so processes. It calls the other classes and executes their threads. The class BinarySemaphore.java implements the wait () and wakeup (), that is, acquire () and release () methods for displaying synchronisation and concurrency in the subsystem 2. The class CountingSemaphore.java define threads permits The class PutPIValues.java extends the main class FADEC.java and implements the thread allowing the FADEC controller to store fuel pressure and ignition values in their repository. The class GetPIValues.java extends the main class FADEC.java and implements the thread allowing the engine controller to get fuel pressure and ignition values in their repository. The class PerfectStatus.java extends the main class FADEC.java and implements the thread displaying the Green colour (perfect status of FADEC working components). The class MinorError.java extends the main class FADEC.java and implements the thread displaying the Yellow colour (all components working properly and only a minor error being corrected). The class SomeIssues.java also extends the main class FADEC.java and implements the thread displaying the Orange colour (Some components are facing issues; issues being fixed).
25
3.2. Application code lines with descriptions

The main class FADEC.java (Both subsystems)
package semaphore_sync_runbl; //import Random object to healp displaying output in the subsytem 2 randomly. import java.util.Random; public class FADEC { /* Below are thre use of protected and static methods to call Binary and Counting Semaphore objects in the extended classes. */ protected static final BinarySemaphore binarySemaphore0 = new BinarySemaphore(0); protected static final BinarySemaphore binarySemaphore1 = new BinarySemaphore(1); protected static final CountingSemaphore countingSemaphore = new CountingSemaphore(0); protected static final Random random = new Random(); // Following is the start excecution of all the program threads in the main method public static void main(String args[]) throws InterruptedException { new Thread(new PutPIValues()).start(); Thread.sleep(2000); new Thread(new GetPIValues()).start(); Thread.sleep(1000); new Thread(new PerfectStatus()).start(); new Thread(new MinorError()).start(); new Thread(new SomeIssues()).start(); Thread.sleep(5000); } }
The class BinarySemaphore.java (Both subsystems)

package semaphore_sync_runbl; /* This class uses the synchronisation constructor (BinarySemaphore) and the synchronisation methods waitForNotify(to make the thread in a waiting state if there is or are other threads processing) and notifyToWakeup(to take the semaphore which already invoque a thread into the waiting queue). */ public class BinarySemaphore { private boolean locked = false; BinarySemaphore(int initial) { locked = (initial == 0); } public synchronized void waitForNotify() throws InterruptedException {
26
while (locked) { wait(); } locked = true; } public synchronized void notifyToWakeup() { if (locked) { notify(); } locked = false; } }
The class CountingSemaphore.java (Both subsystems)

package semaphore_sync_runbl; /* This class uses the synchronisation constructor (CountingSemaphore) and the synchronisation methods waitForNotify(to decrease the semaphore counter) and notifyToWakeup(to increase the semaphore counter. */ public class CountingSemaphore { private int value = 0; private int waitCount = 0; private int notifyCount = 0; public CountingSemaphore(int initial) { if (initial > 0) { value = initial; } } public synchronized void waitForNotify() { if (value <= waitCount) { waitCount++; try { do { wait(); } while (notifyCount == 0); } catch (InterruptedException e) { notify(); } finally { waitCount--; } notifyCount--; } value--; } public synchronized void notifyToWakeup() { value++; if (waitCount>notifyCount) {
27
notifyCount++; notify(); } } }
The class PutPIValues.java (Subsystem 1)

package semaphore_sync_runbl; /* Importation of the Date object to apply and display current dates during processes performance. */ import java.util.Date; /* This extends the main class FADEC.java and implements the thread putting pressure and ignition values from the repository. The operation ends because the system just needs some values to start the engine. */ public class PutPIValues extends FADEC implements Runnable{ @Override public void run(){ System.out.println(new Date()+ "\t Start putting pressure and ignition values in the repository..."); for(int i = 1; i <= 2; i++) { System.out.println(new Date()+ "\t pressure & ignition values "); } System.out.println(new Date()+ "\t Operation ends!"); } }
The class GetPIValues.java (Subsystem 1)

package semaphore_sync_runbl; /* Importation of the Date object to apply and display current dates during processes performance. */ import java.util.Date; /* This extends the main class FADEC.java and implements the thread getting pressure and ignition values from the repository. The operation ends because the system just needs some values to start the engine. */ public class GetPIValues extends FADEC implements Runnable{ @Override public void run() {
28
System.out.println(new Date()+ "\t Start getting pressure and ignition values from the repository..."); for(int j = 1; j <= 2; j++) { System.out.println(new Date()+ "\t pressure & ignition values "); } System.out.println(new Date()+ "\t Operation ends!"); } }
The class PerfectStatus.java (Subsystem 2)

package semaphore_sync_runbl; /* Importation of the Date object to apply and display current dates during processes performance. */ import java.util.Date; /* This class mainly performs the display of the perfect status of components during the whole operation. It extends the main class FADEC.java and implements the thread displaying many Green status with its comment for a while and using the binarySemaphore object. */ public class PerfectStatus extends FADEC implements Runnable { public void run() { while(true) { try{ Thread.sleep(1+ (int) (random.nextDouble() * 200)); } catch(InterruptedException e1) { e1.printStackTrace(); } System.out.println(new Date()+ " :'Green': All the components working perfectly !!!!!"); countingSemaphore.notifyToWakeup(); } } }
The class MinorError.java (Subsystem 2)

package semaphore_sync_runbl; /* Importation of the Date object to apply and display current dates during processes performance. */ import java.util.Date; /* This class mainly performs the display of fiew minors errors status during the whole operation. It extends the main class FADEC.java and implements the thread displaying randomly few Yellow status with its comment for a while and using the binarySemaphore object. */ public class MinorError extends FADEC implements Runnable {
29
public void run() { while(true) { try{ Thread.sleep(1+ (int) (random.nextDouble() * 400)); binarySemaphore1.waitForNotify(); } catch(InterruptedException e) { e.printStackTrace(); } countingSemaphore.waitForNotify(); System.out.println(new Date()+ " :'Yellow': All components working properly; Only a minor error being corrected...." ); binarySemaphore0.notifyToWakeup(); } } }
The class SomeIssues.java (Subsystem 2)

package semaphore_sync_runbl; /* Importation of the Date object to apply and display current dates during processes performance. */ import java.util.Date; /* This class mainly performs the display of fiew issues status during the whole operation.extends the main class FADEC.java and implements the thread displaying randomly very few Orange status with its comment for a while and using the binarySemaphore object. */ public class SomeIssues extends FADEC implements Runnable { public void run() { while(true) { try{ Thread.sleep(1+ (int) (random.nextDouble() * 900)); binarySemaphore0.waitForNotify(); } catch(InterruptedException e) { e.printStackTrace(); } countingSemaphore.waitForNotify(); System.out.println(new Date()+ " :'Orange': Some components are facing issues; Issues being fixed..........."); binarySemaphore1.notifyToWakeup(); } } }
30
3.3. Program outputs
31
Figure 9: Application outputs for 10 seconds run
Description The data flow diagram focus on the operation from the engine start processes to engine running processes, in other words before the engine shutdown. The program being considered as a real time application, that means should not normally stop running until the end of the operation or until an event occurs. This is why, in order to demonstrate the outputs behaviour of the program, the run has been stopped after 10 seconds.
32
The Date object has been implemented detailing date parameters namely the day, the month, the date of the month, the time (hour, minutes & seconds) the time system and the year. This implementation aims to demonstrate concurrent processes during the operation. On Thursday 21 March 2013 exactly at 14:58:22, fuel pressure and ignition values are stored in the repository by the FADEC Controller. On Thursday 21 March 2013 exactly at
14:58:23, fuel pressure and ignition values are then got from the repository by the engine controller. The difference of 1 second shows the synchronisation on the repository access, therefore means that values first need to be put before being got. We also notice that the first process ends before the other starts. The second process (getting values) then ends before the monitoring system effectively start. From Thursday 21 March 2013, exactly at 14:58:24 to Thursday 21 March 2013, exactly at 14:58:32, the concurrent monitoring operation is performing. That is, the HAS monitoring system is controlling all the components status by displaying Green for perfect status; Yellow for good status with minor error and Orange for the status having some issues. In that concerns the Yellow and Orange status, the outputs also show that the error and issues are being fixed. On Thursday 21 March 2013, exactly at 14:58:31, we can also notice that the three processes (Green, Yellow, and Orange; including corresponding statements) are performing all. That shows the concurrency concept of the application.
33
Summary
To sum up, the work consisted of first searching, selecting a suitable real time application, describing the application by emphasizing on its software are hardware components, the way it works and providing its data flow diagram. Secondly, we had to provide detailed explanations about synchronisation and communication issues within real time and embedded systems with insistence on the mechanisms used, and particularly the mechanism chosen for our real time application. Besides it was about to chose and describes some real time operating systems. Finally, we had to implement some processes within the chosen application through java programming language and using suitable coding mechanisms. To come up with the solution to asked questions, the following steps have been carried out. A real time application on the field of aircraft, called FADEC (Full Authority Digital Electronic Control) system has been selected after some research conducted through internet. A detailed description of the application has been provided with the conclusion that the FADEC system is a hard real time application. The data flow diagram of some scenario steps within the application has also been designed. Synchronisation and communication mechanisms within real time and embedded systems have been discussed with encountered issues. Some mechanisms among other have been discussed such as semaphore, monitors, message passing and rendezvous with a particular interest on semaphore as the one to be used for the application implementation. Alongside has been selected and discussed some real time operating systems including LynxOS, Integrity and RTLinux. Finally, 5 processes from FADEC data flow diagram have been chosen and implemented through java programming language. Some comments have been provided to the code lines and detailed description of the application outputs has also been produced. We cannot claim having completed totally and perfectly the assigned task. However, further answers to asked questions have been provided and we modestly think that this work is a real contribution for future work and research on the fields of real time and embedded systems, real time applications and real time operation system.
34
List of references
Baskiyar, S., and Meghanathan, N. (2004) A Survey of Contemporary Real-time Operating Systems. Auburn: Department of Science and Software Engineering Auburn University Burns ,A., and Wellings., A (2001) Real-Time Systems and Programming Languages. 3rd edn. Addison Wesley Longmain Cedeo, W., and Laplante, P, A. (2007) An Overview of Real-Time Operating Systems. 3rd edn. A Johan Willey & Sons, Inc., Publication FADEC International (n.d.) Fadec Users Manual. V1.3 10/3/99. Green Hills Software (2011) Integrity: The most advanced RTOS Technology Horning, J. (ed.) (1978) Distributed Processes: A Concurrent Programming Concept Japenga, B., ( n.d.) Why use Linux for Real time and embedded system Laplante, P, A., (2004) Real-Time Systems Design and Analysis. 3rd edn. Wiley-IEEE Press LynuxWorks (2005) LynxOS 4.0: The worlds most powerful, open-standards RTOS The Finite State Machine Labs Inc (2001) RTLinux FAQ University of Gothenburg's LMS (2013) FADEC
Green Hills Software (2013) Customers Goodrich [online] available from <http://www.ghs.com/AerospaceDefenseCustomers.html> [04 March 2013] Linuxforyou, (2010) Getting Started with RTLinux [online] available from <http://www.linuxforu.com/2010/12/getting-started-with-rtlinux/> [01 March 2013] Mbed (2012) RTOS [online] available from < http://mbed.org/handbook/RTOS> [13 March 2013] Safran Sagem (2013) ENGINE CONTROL UNITS <http://www.sagemds.com/spip.php?rubrique16&lang=fr> [25 February 2013] Wikipedia (2013) LynxOS [online] available from < http://en.wikipedia.org/wiki/LynxOS> [10 March 2013]
35

Real Time Embedded Systems

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Real Time Embedded Systems

Загружено:

Авторское право:

Доступные форматы

Coventry University- Faculty of Engineering and ComputingM25CDE (Real-Time and Embedded systems) 2013

M25CDE Coursework Real-Time Application

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

List of figures and tables

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

1. Part 1 Full Authority Digital Engine Control

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

1.2. FADEC operating scenario and Data Flow Diagram (DFD)

Figure 2: Sample of a FADEC control chain

Gilles Rubens Badouet

- MSc Network Computing Course Cours -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

1.2.2. FADEC Data Flow Diagram (DFD)

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Figure 3: DFD of FADEC system

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

2.2. Semaphore synchronisation mechanism

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Table 1: Comparison between Semaphore and other major mechanisms

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

2.3. Real Time Operating System (RTOS)

Figure 5: Threads states (Mbed, 2012)

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

2.3.2. Facilities/roles and RTOS requirements

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013

Gilles Rubens Badouet

- MSc Network Computing Course -

Coventry University 2013