Platform-Based Embedded Software Design for Multi-Vehicle Multi-Modal Systems

Platform-Based Embedded Software Design for Multi-Vehicle Multi-Modal Systems T.John Koo,Judith Liebman,Cedric Ma,Benjamin Horowitz,AlbertoSangiovanni-Vincentelli,Shankar SastryDepartment of Electrical Engineering and Computer SciencesUniversity of California at BerkeleyBerkeley,CA94720Abstract.In this paper,we present a methodology for the design of em-bedded controllers for multi-vehicle multi-modal systems.Our method-ology is predicated upon the principles of platform-based design,whichuses layers of abstraction to isolate applications from low-level systemdetails and yet provides enough information about the important param-eters of the lower layers of abstraction,to modularize the system designand to provide predictable system performance.An essential layer ofabstraction in our methodology is the software platform provided bythe programming language Giotto,which allows a clean implementa-tion of a time-based controller application.Our methodology includes ahardware-in-the-loop simulation framework,in which system componentscan be replaced by actual implementation for high-fidelity simulation.Todemonstrate the effectiveness of our design methodology,a helicopter-based unmanned aerial vehicle system is presented.We present simula-tion results which validate the quality of our embedded control systemimplementation.1IntroductionIn the future,satellites will form a rigid structure to perform distributed obser-vations.In automated highway systems(AHS),platoons of cars will be formed to enhance efficiency.Clusters of unmanned aerial vehicles(UAVs)will maintain formations to accomplish missions collectively in restricted areas.However,in order for distributed,network-centric,embedded systems to deliver high levels of mission reliability,they require high-confidence embedded software[8]:the embedded systems should ideally be correct by construction,fault-tolerant,and resistant to information attack.Therefore,the embedded software,which is used for the processing of information to and fro between the information and phys-ical worlds,has to be designed in such a way that the embedded system can exhibit multi-modal behaviors for coping with different scenarios due to changes in the environment.However,current design strategies for embedded software in control applica-tions deal with system requirements and characteristics using ad hoc approaches. One of the most serious problems is the current disregard for the interaction ofthe control laws with their implementation.When a control law is designed,the computational power of the implementation platform is grossly estimated.This neglect leads to long re-design cycles when the timing requirements of the ap-plications are not met.This situation has its origin in the difficulty of mixing implementation and functional design,and in the difficulty of evaluating quickly an alternative control law or implementation architecture.Another problem is the deficiency in component re-usability.Reusing components that are specific to function or implementation decreases time-to-market and validation time. Assuming a component is fully validated,the difficulty is in composing these objects to work properly.This paper proposes a methodology where the dichotomy between functional design and implementation is bridged and the issues related to component re-use are addressed.One main goal of our design strategy is to build in modularity in order to make code reuse and substitutions of subsystems simple.The other main goal is to guarantee performance without exhaustive testing.To achieve these goals we draw on the principles of platform-based design[12].A platform, in this context,is a layer of abstraction that hides the unnecessary details of the underlying implementation and yet carries enough information about the layers below to prevent design iterations.We achieve the latter goal by using a time-based controller.In particular,the choice of a specific software platform to guarantee correct timing performance for the control laws is of interest.Here we focus on the Giotto[4,5]software platform and we show how this software platform substantially aids the development of embedded software.Giotto con-sists of formal semantics[5]and a retargetable compiler.Giotto has already been used to redesign the helicopter control systems developed at UC Berkeley[6]and ETH Z¨u rich[7].There are related software platforms,such as the synchronous language Esterel[1]and Lustre[3],or the Open Control Platform(OCP)[15] being developed.A tool called Taxy[2]is especially developed to verify real-time properties of embedded systems in which Esterel is used to specify control flow of software components.OCP uses real-time CORBA(Common Object Re-quest Broker Architecture)which is an object-oriented middleware to provide interoperability among heterogeneous software components.However,the major difference between the Giotto software platform and those software platforms is that the execution of control applications on the Giotto software platform are guaranteed to be correct since Giotto is designed to have well-defined se-mantics for executing periodical tasks and for performing deterministic mode switchings.There also exist computer architectures,such as the Time-triggered Architecture[10,9],which consider both hardware and software components for the construction of high-confidence embedded systems.In order to validate the performance of embedded system implementation in the presence of faults and information attack,a hardware-in-the-loop simula-tion(HILS)framework is introduced.In a HILS,part of the simulated system is replaced by actual implementation in order to obtain a more useful simu-lation result.Any anticipated or unanticipated faults can be injected into the system during the hardware-in-the-loop simulation for testing the robustness ofthe design.Another key feature of a HIL simulator is its ability to test the actualcontrol implementation and embedded hardware instead of just the control laws.Due to the complexity of communication networks,it is difficult to obtain ac-curate network models for simulation.By using HILS,an actual communicationnetwork can be used and the system performance in the presence of the networkcan be examined.Fig.1.A leading UAV and two following UAVsfly in a wedge formation.Each vehiclecan localize itself by processing the received GPS signal and each follower can stay ina location relative to the leader by using the leader’s information obtained from thewireless network.The structure of this paper is as follows.In Section2,we introduce the readerto the principles of platform-based design and we describe a software platformfor programming time-based controller applications.We present the principlesand construction of a HILS in Section3.Finally,in Section4,we present theembedded control system and HILS for a UAV.The difficulty and complexityof the application serve well the purpose of accentuating the features of thedesign method and demonstrating its power.The choices of design solutionsare somewhat application-dependent but the overall idea is not,so that thisexample could provide a general guideline for the application of our method.Wethen extend the system design to multiple UAVsflying in formation(as depictedin Figure1).2Platform-Based Design MethodsAn embedded control system generally consists of three elements—sensors, actuators,and a computer.The control computer interacts with the continu-ous dynamics of the plant via the sensors and actuators.For each vehicle,we assume that there is only one computer system and its major function is to com-pute and generate control commands for the actuators that are based on sensor measurement.A high-confidence embedded system should be designed so that its physical behavior can be easily analyzed and predicted.However,it is also important that the embedded system can be composed from a variety of heterogeneous compo-nents while satisfying the design specifications.Therefore,there is a demand for an approach to facilitate both time-based design and modular design:A time-based design.The system should be time-based in order to allow easyanalysis of its closed loop behavior.However,the system must maintain com-patibility with existing devices such as the sensors,which are not necessarily time-based.A clear boundary between the system’s synchronous and asyn-chronous elements must be drawn,and provisions must be made to bridge the gap.A modular design.The new system must allow the designer to choose froma diverse mix of sensors,actuation schemes,and controllers.The new sys-tem must allow a configuration of the same software to run on different helicopters,which may have very different physical dynamics and devices.To meet this design challenge,we draw on the principles of platform-based design.A platform is defined as a layer of abstraction which hides details of the underlying implementation,and through which only relevant information is allowed to pass.The main principle of platform-based design is that systems should employ precisely defined layers of abstractions.For example,a device driver provides a layer of abstraction between an operating system and a device. This layer hides most of the intricacies of the device,but still allows the operating system to configure,read from,and write to the device.Designs built on top of platforms are isolated from irrelevant subsystem details.A good platform provides enough useful information so that many applications can be built on top of it.Typically,a system can be presented as the combination of a top level view, a bottom level view,and a set of tools and methods to map between the views. On the bottom,as depicted in Figure2,is the architecture space.This space includes all of the options available for implementing the physical system.On the top is the application space,which includes high level applications for the system and leaves space for future applications.These two views of the system, the upper and the lower,should be decoupled.Instead of interacting directly,the two design spaces meet at a clearly defined interface,which is displayed as the shared vertex of the two triangles in Figure2.The fact that the two spaces meet at one point conveys the key idea that the platform exposes only the necessaryand relevant information to the space above.The entire figure,including the top view,the bottom view,and the vertex,is called the system platform stack .PlatformStackSystemPlatformInterfaceFig.2.The system platform stack2.1A Time-Based Control Platform:GiottoControl laws for autonomous vehicles are typically implemented on architec-tural platforms consisting of sensors,actuators,and computers which contain programmable components (e.g.,micro-processors,DSPs)and memory (e.g.,flash,RAM and ROM).The control laws are almost always implemented as software stored on ROM or flash memory running on the programmable compo-nents.There are often difficulties in mapping the control laws onto these kind of architectural platforms:–In most cases,the controller must react in real-time.A software implemen-tation is intrinsically slower than hardware.In addition,the computing part of the platform usually consists of a standard single microprocessor.Thus,the concurrency of the function to implement is lost:concurrent tasks have to be sequentialized.These platforms are equipped with a real-time operat-ing system (RTOS),i.e.,a light-weight,low-overhead,operating system that schedules tasks to be executed on the processor.There are many scheduling algorithms (e.g.rate monotonic,earliest deadline first,and their variants)available to optimize the processor utilization while maintaining deadlines for task execution.The most popular RTOSs support rate-monotonic scheduling algorithms.–In the implementation of the control laws,the control designer must take into account the possibilities of inaccuracies and malfunctions in the sensors and actuators.However,if the software implementation directly uses informationabout the particular peripherals of the platform,then re-using the software on different platforms would be virtually impossible.An efficient solution for this problem is to use device-geared software processes to isolate the control software and the algorithms from the physical characteristic of the devices.In order to ameliorate these problems,we introduce a new abstraction layer which will sit between the RTOS and the functional description of the control laws.This abstraction layer will provide the control designer with a more rel-evant and direct method for programming the control laws to meet real-time constraints.However,the control designer must adhere to the guidelines that this abstraction allows.In this way,the abstraction layer will restrict the design space available to develop the control laws,but will significantly shorten the design time and ensure the correctness of the design.To illustrate this idea using the hourglassfigure of platform-based design,we place the possible control laws in the application space on top,and the RTOS in the architecture space on the bottom.The proposed abstraction layer makes up the interface between these two views.Ideally,this platform interface should pass the timing constraints of the application downwards,and should pass the performance capabilities of the architectural instance upwards.On the basis of these constraints,the platform’s tools should be able to determine whether the timing requirements of the application can be fulfilled.In the next section,we discuss in detail an abstraction layer between the RTOS and the real-time control laws that is chosen for the helicopter embedded software.This abstraction layer is the Giotto programming language.2.2Giotto ProgramControl applications often have periodic,concurrent tasks.For example,our UAV control application runs a measurement fusion task at a frequency of100 Hz,and a control computation task at50Hz.These periodic tasks communicate with each other.The mechanisms used to implement such a communication pathway—whether they may be message queues,shared memory,or some other mechanisms—may vary depending on the operating system and the preference of the designer.Control applications also need a means to receive input from and send output data to the physical environment.Finally,control applications often have distinct modes of behavior;in two different modes,different sets of concurrent tasks may need to run,or the same set of tasks may need to run but at different rates.Giotto provides the control designer a way to specify applications with periodic,concurrent,and communicating tasks.Giotto also provides a means for I/O interaction with the physical environment,and for mode switching between different sets of tasks.Consider the example program of Figure3.The concurrent tasks—Fusion and Control—are shown in thefigure as rounded rectangles.Each task has a logical execution interval.In our example,Fusion logically executes from0 ms to10ms,from10ms to20ms,etc.,whereas Control logically executes from0ms to20ms,from20ms to40ms,and so on.Each task has inputFig.3.An example Giotto programports and output ports,shown as black circles.A task’s input ports are set at the beginning of its logical execution interval.During its execution,the task executes some computation,and the results are written to its output ports at end of its logical execution interval.For example,the input ports of Fusion are set at0ms;between0ms and10ms,Fusion computes its function;at10ms, the result of this function is written to Fusion’s output ports.A Giotto program may also contain sensors and actuators,both of which are depicted as white circles.Rather than being actual devices,sensors and actuators are programming language constructs which let the programmer define how to input data into and output data from a Giotto program.Logically,sensors and actuators are passive:they are polled at times specified in the Giotto program, and cannot push data into the program at their own times.Our example program has two sensors,GPS and INS,and one actuator,Servos.The sensors are read at0ms,10ms,20ms,etc.,and the actuator is written at0ms,20ms,and so on.Tasks communicate with each other,and with sensors and actuators,by means of drivers,which are shown as diamonds.In Figure3,the drivers connect the GPS and INS sensors to the input ports of the Fusion task.They also connect the output port of Fusion to the input port of Control,and the output of Control to the Servos actuator.Thus,the Fusion task which executes between 0and10ms receives its inputs from the GPS and INS readings at0ms.Similarly, the Control task which starts at0ms receives its inputs from the Fusion task whichfinishes at0ms,and writes its outputs to the Servos actuator at20ms. 3Hardware-In-The-Loop SimulationIn this section,we discuss a hardware-in-the-loop simulation(HILS)system use-ful for the development of multi-vehicle multi-modal embedded systems.Em-bedded control systems can be viewed as two subsystems:a system under test (SUT),which is the embedded controller,and an environment.The environment contains all the elements that the SUT needs to interact with.HILS makes it pos-sible to conduct comprehensive testing of an embedded system by replacing thereal-world environment at the device’s input-output interface with a simulated environment.HILS is particularly effective when normal testing is dangerous or costly since it facilitates repeatable testing.Though the HILS methodology pro-vides an effective means for testing,its use requires care,especially if simulation results are to be accepted as assurance about real-world safety and performance.A HILS methodology places stringent requirements on the implementation of the environment since the environment is usually modeled by sets of differ-ential equations.Hence,the simulator which implements the environment needs to operate sufficiently fast in order to meet the hard deadlines.It therefore requires careful selection of underlying numerical methods[11]for solving dif-ferential equations.This constraint also greatly limits the choice of operating systems available to run the simulator.Since accurate multi-vehicle simulation may be computationally intensive,a HILS should be able to scale to parallel execution on multiple interconnected computers.4Case Study:End to End Design of Helicopter Based UA VIn this section we discuss strategies for building a helicopter based UAV control system and HILS,with two main goals in mind.1.Thefirst goal is to incorporate both asynchronous input devices and a time-based controller.Conventionally,sensors are designed to send data at their own,possibly drifting,rates.However,a time-based controller reads from input devices at its ownfixed times.Thus,combining these components gives rise to a mismatch in timing behavior which needs to be addressed.2.The second goal is to build a system that is modular enough to allow onesuite of devices(e.g.,a sensor suite)to be replaced by another.To achieve these two goals we will demonstrate the use of the principles of platform-based design.We will show how a layer of abstraction between the devices and the controller can be used to bridge the timing mismatch and to allow for the inclusion of different sensor suites.4.1Building Functional Description using Platform-Based Design In Section2we explained how to begin the platform-based design process by separating the system into two views:the application and the architecture.Here we apply this separation to our helicopter based UAV.From the top,a designer sees the time-based control application.From the bottom,a designer sees the available physical devices,such as the vehicle,the sensors,and the actuators. Following the meet-in-the-middle approach of platform-based design,we include an intermediate abstraction layer,the UAV platform,whose top view is suit-able for time-based control and whose bottom view is implementable using the available devices.We next describe the functionality of the UAV platform.Interaction with devices.The UAV platform should be able to receive data from the sensors at their own rates and without loss of data.Similarly,the platform should be able to send commands to the actuators in the correct formats.It will also need to initialize the devices.Furthermore,the platform should be able to carry out these interactions with a variety of different sensor and actuator suites.Interaction with control application.The UAV platform should provide mea-surement data to the control application in the format and at the frequency dictated by the controller.Similarly,the platform should receive the com-mands from the controller at the controller’s rate,and immediately send them on to the actuators.The platform should also be able to support a variety of controllers.One natural conclusion is that the platform should buffer incoming data from the sensors,convert sensor data into formats usable by controller applications, and convert control commands into formats usable by actuators.In Section4.2 we describe in detail two ways to implement the functions of the platform.4.2Implementing Functional Description using Platform-BasedDesignIn this section we begin by discussing the realization of the controller application. This implementation,as discussed above in Section4.1,places constraints on the platform.Platform implementations which meet these constraints are presented next.Implementing the Controller Application To attain the benefits of time-based control,the controller application is realized using the Giotto programming language.The two essential tasks for the controller are Fusion and Control. Fusion combines the INS and GPS data using a Kalmanfilter and is run ata frequency of100Hz.Control uses the output from Fusion to compute the control law shown in[6]at a frequency of50Hz.The frequencies of these two tasks are chosen based on the expectations of the control law and on the limitations of the devices.Each task is written as a separate C function.These C functions are referenced inside of the Giotto program,which schedules and runs them.Implementing the UA V Platform Having considered a realization of the time-based controller,we now turn to the UAV platform.In Section4.1,we dis-cussed the requirements that our UAV platform needs to fulfill.We now present a possible implementation of the UAV platform which fulfills these requirements. The implementation uses one computer,effectively implementing in software the buffer discussed in Section4.1.The single computer implementation has three main elements,which are depicted in Figure4.UAVPlatformImplementationFig.4.First implementation of UAV platformData processor.The data processor is an independent process,similar to a standard interrupt handler.In the sensing case,it responds to the new sen-sor data sent by the devices,and saves this data to a shared memory space with the sensor specific data format intact.In the actuating case,the data processor passes on to the servos the messages sent by the controller appli-cation.Shared memory.The shared memory contains recent sensor readings,and is implemented as circular buffers.Data are placed into the circular buffers by the data processor,and can be accessed by the controller application.In this way the controller application can grab the sensor data without worrying about the timing capabilities of each sensor.Data formatting library.Within the controller application,the sensor spe-cific data format must be converted to the format that the control compu-tation expects.In the sensing case,the controller application uses the data formatting library to transform the buffered sensor readings.In the actu-ating case,the controller application uses the library to convert actuation commands into the format expected by the servos.Recall from Section2.2that the controller application comes with guarantees about the deadlines of its own internal tasks.These guarantees,however,do not take into account the time that may be needed by other processes or interrupt handlers.If more than a negligible amount of time is spent in the other processes, then the timing guarantees of the controller application may cease to be valid. For this reason,the above design keeps the time needed by the data processor to a bare minimum.The data transformations necessary are instead written into the data formatting library and called from within the control tasks.The benefit of this approach is that the timing guarantees of the controller application arepreserved, as much as possible. It may appear that the mixture of aperiodic tasks (reception of sensor data) and periodic tasks (Giotto tasks) makes it difficult to guarantee that Giotto tasks will meet their deadlines. However, one can use well-known server techniques, like the deferrable server[14] or the sporadic server [13], to provide fast response times for the reception of sensor data, while still guaranteeing that the deadlines of periodic tasks (in this case, Giotto tasks) will be met. To perform the direct testing of the entire control system discussed in this section, we propose the use of a HIL simulator with the properties outlined in Section 3. Instead of mounting the control system onto the helicopter, the embedded control system, or SUT, is connected to a simulation computer. The proposed simulation framework, in combination with platform-based design, allow for the development of automation control systems that are modular and have guaranteed performance. 4.3 Hardware-in-the-Loop SimulationsIn this project we have obtained results through the combination of the controller application running in Giotto and the platform implementation presented in the previous section, and a realization of a HIL simulator.Fig. 5. a. Graphical flight display; b. Flight capable hardware with real-time operating systems.The controller application, along with the realization of the platform currently runs on a flight capable computer running VxWorks. This control computer communicates with the HIL simulation computer using a high speed serial connection. The HIL simulator uses the dynamic model of the Yamaha R-50 whose origin is presented in [6]. The simulator generates the states of the model by using a numerical ODE solver. It also runs on the VxWorks real-time operating system. In order to visualize the performance of the overall system which consists of the Giotto controller, platform realization, and the HIL simulator,the current state of the simulated helicopter was sent via network to a 3-D visualization program where the helicopter is rendered on screen. Figure 5a is a screen shot of this program. Experimental Results Numerous test flights have been performed by ‘flying’ our Giotto and UAV platform embedded control system on the HIL simulator. In one series of test flights we configured the control task, which runs from within the Giotto program, to fly in a triangular flight pattern. The triangular pattern consisted of a repetition of the following modes of flight: Takeoff : Flight in the forward and upwards directions at a 45 degree angle. Flight : Flight in the backwards direction with no heading change. Landing : Flight in the forwards and downwards directions at a 45 degree angle. The desired velocities and heading references are displayed in Figure 6a. Figure 6b shows the actual velocities and heading output by the HIL simulator during a real-time test flight. By comparing the figures, one can conclude that the simulated helicopter follows very closely the desired references. This result attests to the accuracy of our embedded control system in implementing the control laws and to the usefulness of the hardware-in-the-loop simulator.Fig. 6. a. Desired output setpoints; b. Simulated output trajectories.Figure 7a shows both the changing desired forward velocity, and the actual forward velocity output by the HIL simulator. Figure 7b shows the changing desired downwards velocity as compared to the actual downwards velocity. The two remaining figures, 7c and 7d, show the actual sideways velocity or heading with a desired velocity and a heading of zero. These data only begin to illuminate the possible utility of the HILS. For example, flight mode switching anomalies can easily be compared between controllers. Furthermore, this simulation framework could be put to work simulating multiple helicopters flying in formation.。