HW SW Co Design Avionics Communication Protoco IndustrialCaseStudy

8/13/2019 HW SW Co Design Avionics Communication Protoco IndustrialCaseStudy

1/5

Hardware/Software Co-Design of an AvionicsCommunication Protocol Interface System:an Industrial Case Study

Franqois Clout6Laboratoire dElectronique LEN7ENSEEIHT, 2 rue Camichel

31071 Toulouse Cedex 07, France33.5.61.56.64.36

[email protected]

Pascal PampagninAEROSPATIALE ABronautiqoeDirection Systemes et Services


pascal.pampagnin~avions.aerospatiale.fr

ABSTRACT

Jean-Nod ContensouLaboratoire dElectronique LEN7ENSEEIHT. 2 rue Camichel


Philippe PonsAEROSPATIALE AeronautiqueDirection Systhmes et Services


Daniel EsteveLaboratoire dElectronique LEN7ENSEEIHT. 2 rue Camichel


esteve~ten7.snseeiht.frYves Favard

AEROSPATIALE AhronautiqueDirection Systemes et Services


[email protected]

Hardware/Software co-design is not a new idea, since designershave been used 1o mixing programmable and specific hardwarecomponents for algorithms implementation. However, with thegrowing complexity of systems, a computer-aided co-designmethodology becomesessential.This paper presents an application of the avionics domain: theARINC communication pmtocol interface system.The w-designapproach is based on the POLIS framework, coupled with theWere1 specification language.KeywordsCo-design, avionics, ARlNC, Ester4 POLK1 INTRODUCTIONThe major constantly growing factor that limits the developmentof complex systems s not the silicon technology manufacture,butthe lack of a system-level design methodology. The increasingwidespread of embedded systems in the domains of vehicle,avionics, communication, erc, emphasizes hat need.Unlike a general-purposecomputer, an embeddedsystem has torealize a well-defined set of specific tasks. The requiredspecialization should alter minimally its flexibility, to get amaximum design re-use 161.Thus an embedded system typically consists of some VLSIhardware components, like ASK or FPGA, and sofiwaresupported by standard programmable components, ike RISC orDSP.

In a modem commercial aircraft, the avionics (i.e. the set of on-board hardware and software electronics equipment) consists ofabout a hundred of computers communicating between them andthe environment Each of thesecomputers s dedicated o a specificavionics function. Such critical systems require a certifieddevelopment.Currently, the design of an embedded ystem s not optimal:1. the system specification is written in a natural language,eventually without abstraction of architectural d&Is;2. the architectural decisions are made a priori, following thearchitectsexperience or/and the past product versions;3. the hardware and software pa are developed too

separately;4. the software is tested only after the hardware/softwareintegration on a real prototype;An hardware/sofiware co-design methodology aims at solving allthose ssues15.7, and 101.Co-design is defined as a methodologyfor designing software and hardware concurrently, thus reducingthe design time and time-to-market. Hardware/software co-designof embedded system includes co-specification,hardware/software pxtitioning, architecture selection, co-synthesis and co-verification.There are different approaches f co-design, related to the type ofthe target applications. The taxonomy of embedded systemsdistinguishes two main domains: control-miented and data-dominated applications.In data-flow applications, e.g. digital signal processing, thebehavior of the system s scheduled at a fixed rate, and the maincomplexity o f the design comes rom the mathematical operationson data. In control-oriented reactive applications, the systemreacts continuously to the environment. Then, the monitoring of

48


2/5

the different tasks is crucial, especially as there are real-timeconstraints 12, 121. The distinction is trivial, since very complexsystems deal with both. But designing them requires a separatepoint of view.Ibis paper describes the hardware/software co-design of anavionics embedded control-dominated system: the ARINCprotocol interface system. The next section provides somebackground about the ARINC protocol interface. Section 3considers the system specification with an Esterel overview.Section 4 presents the POLlS co-design approach. Section 5highlights some experimental results about the hardware/softwaredesign space exploration. Section 6 concludes and discussesfuture work.2 THE AVIONICS ARINC PROTOCOLINTERFACEIn a modem commercial aircraft, the avionics consists of about ahundred of computers communicating between them and theenvironment.The ARINC (Aeronautical Radio Inc.) is an international standardwhich specifies the communication protocol between the differentembedded systems on board. Thus embedded systems designed bydifferent manufacturers can communicate in the same aircraft. Thestandard protocol defines the type of the data frames and theexchange format of those data However, the requirements do notforce the implementation.?be ARINC protocol is a serial communication protocol with arate of 100 Kbits per second. Data packets are 32 bits, added to 4bits for the synchronization. A data packet consists of an g-bitidentification field, a 23-bit data field, and one parity bit. AnARINC bus is a set of channels, each canying data packets.The ARINC interface system is in charge of the acquisition of thedata packets received on several parallel input channels. For eachchannel, after the synchronization bits, the recognition and theparity checking, the message is received. For each message true tothe ARINC pattern, an address is computed from the identificationfield to store the data field and dating information . A pre-programmed memory is used for the addressing. Concurrently, theenvironment asynchronously requests the ARINC interface toreturn the available data.The ARINC interface system represents a critical real-timeembedded system, both with a complex control based on datavalues and soft/hard timing constraints.The use of a co-design methodology aims at providing a rigorousdesign, ended in a final prototype with an adequatehardware/software architecture. The methodology we used issupported by POLIS [l], a co-design framework developed at theBerkeley University. The specification language is Esterel [3], areactive synchronous programming language from the INRIAInstitute oi Sophia-Antipolis, France.3 THE ESTEREL SPECIFICATIONEsterel is a textual, imperative, synchronous language, orientedtowards the specification of control-dominated reactive systems.Programming in Esterel is facilitated by a concurrent and modulardecomposition, and an explicit definition of the control by the useof program constructs for concurrency. pre-emption, andexception. Unlike other synchronous languages 181, like Lustre[9] or Signal [ll] dedicated to the computational systems, Esterel

is restricted to the addition of a header file in C for the definitionof procedures or functions.In Esterel, the basic element is the signal, valued or not. emittedby the system or the environment, and at the same time received,according to the synchronous semantics. Time is a multiformconcept, based upon the nature of the signals (time, distance,temperature, etc).The functionality of the ARINC interface was decomposed into 9different modules, with some eventually instantiated more thanonce (i.e. PACKET CONTROL and RAF). The first step was towrite each module in Esterel and to verify it by simulation with agraphical debugger.The ligwe 1 presents the functional decomposition of owmodel of the ARINC interface system.

Figure 1 . Model of the ARlNC interface systemThe data packets coming from each channel are detected, testedwith respect to the ARINC pattern in each concurrent modulePACKET CONTROL. Any accepted packet awakes the process ofthe module SCANNER, which under some conditions, enables theaccess to the pre-programmed memory w ith a priority mechanismfixed by the module ARBITRER. The module ACQ performs thestorage addressin annotated with both dating coming fromDATER, and other information which commands the modulesRAF, WRITE, R/W and MERGE to make the relevant processing tothe data in RAM ?he module R/W reacts also to any read requestfrom the environment.For example, the code shown in figure 2 gives a pat of an Esterelmodule. The reactive behavior is an iniinite loop that tests thepresence of the signal START-RAF. Inside tbe loop, a downcounting is performed from the last value of the signalSTARI-RAF, with an exception handling if tbe internal variableVALEUR is equal to zero. The corresponding trap maintains asignal BIT-IxFAuT-DE-RAF emitted, unless a new signalsTm*-Pxs is received.

49


3/5

.Bloopevery START-RAF dovar VALEUR : integer in%initializationVALEUR := ?START-RAF;

%exception handlingtrap DEFAUT_DEJAF inevery CLK-20MS doVALEUR:=VALEUl-1;if VALEUR=O then exitDEFAUT-DE-RAF; end ifend every

handle DEFAUT-DE-RAF dosustain BIT-DEFAUT-DE-RAF;end trapend arend everyend moduleFtgwe 2. Esterel code

We can compile an Esterel program into a deterministic andsequential finite-state-machine. The table 1 shows the complexityof the ARINC interface, by analogy with the finite-state-machineparameters.

Table 1. Functional decomposition of the complexity of theARINC interface system

A top-level description was specified in Ester& with theacquisition of four input channels, and a simple model o f preprogmmmed memory which infers two storage addresses. TheEstcrel synchronous specification was verified by simulation. Forgiving an approximate idea of the system complexity, thegeneration of one single equivalent finite-state-machine could notnormally terminate under a SPARC IPX Station with 32 Mbytesof ROM. Nevertheless, the generation o f a sorted circuit code in Cis the tight alternative for an all software implementation.As the final ARINC interface system has to cope with up to 80input charm& concurrently, hardware should be essential to meetthe fiming constrain& Thus our Est.& modules were entered inthe POLIS co-design flow.4 THE POLIS CO-DESIGNENVIRONMENTThe POLIS co-design framework is oriented towatds control-dominated reactive embedded systems, with a generic targetarchitecture composed of one microcontroller and some hardwareCOpIOCSWXS.fix POLK environment is based on a formal model called Co-design Finite State Machine (CFSM ). A network of CFSMs, withan asynchronous comm unication model between CFSMs

represents a system. Each CFSM is specified by an Esterelmodule, locally synchmnous.Tbe POLIS design flow is illustrated by the figure 3, and the mainsteps are described below:

Figure 3. The POLL9 system1. Translation of the system-level language like Es&e1 into

the CFSM model;2. Formal verification of the specification after the

translation of a CFSM into a finite-state-machine formalism;3. Manual hardware/software partitioning. The granularity

level is the CFSM;4. Hardware/software co-simulation based on the Ptolemysimolation framework 141. Related to the hardware/software

partitioning, the microprocessor selection, and the schedulerselection, the architectural trade-offs are explored and evaluated,relying on code size and pexfonnaoce estimates of the processor;

5. Hardware synthesis of the CFSM sub-network bymapping into the BLIF (Berkeley Logic Intemwdiate Format)format. Each transition function is a combinational circuit,optimized by logic synthesis techniques , and stales variables areimplemented by registers. Ao XNF netlist can be generated to geta FFGA Xilinx prototype:

6. Software synthesis of the CFSMs sub-network into a Ccode stroctore which includes one procedure for each CFSM anda real-time operating system;

7. Synthesis of the interfaces between the differentimplementation domains: hardware, software, and theenvironment.

SO


4/5

5 THE EXPLORATION OF THEHARDWARE/SOFTWARE DESIGN SPACEThe Esterel specification of the ARINC interface was modified tobe used as a front-end language in the POLIS system, as regardsto its asynchronouscommunication m odel. We altered the code ofsomeCFSMs that react to events coming from at least two distinctCFSMs, in order to get a correct scheduling. Moreover, theMERGE module was added. The Ptolemy graphical user interfaceenables o connect the CFSMs. before functional simulation.POLlS/Ftolemy provides to the user a rich library of componentsfor the test bench. Many simulation scenarii were applied in thePtolemy debug mode. The ARINC interface system with fourinput channels and two-storage index was verified by functionalsimulation.The performance analysis of the system s the key to select auarchitecture that meets the timing constraints. The perfomxmcesimulation relies on the C generatedmodels of each CFSM, thehardware/software partitioning, the scheduling policy chosen forthe operating system, and the timing and cost model of theprocessor.The user can choose a scheduler between a static roundmbin, a static priority with preemptive, or a static priority non-preemptive mechanism.We present in the table 2, for each module and for the wholesystem, the estimated results of the code size in bytes, and theminimum and maximum number of execution cycles of theselectedprocessor.The two 32-bit microcontrollers are the MIPSRISC R3CO0, nd the Motorola 68332.

Table 2. Performance and cost estimated results.The system must both perform the data acquisition of each inputchannel at a speedof IO ps, and respond o the asynchronous eadquest at a minimum interval of 6 vs. The hard timing limit forthe return of a data is 3 ps. We performed worst casesimulations,i.e. with a maximum rate of true ARINC packets , concurrently,over the four channels.We showed that a architecture with a all-softwareimplementation on a MIPS R3000 would require a clockfrequency of 230 MHz, so as not to miss deadlines. Such amicrocontroller do not exist.A more realistic architecture with the four modules (calledCONTROL PACKET, controlling the acquisition of ARINC datapacketsover each channel) mapped o hardware, a MIPS R3000 ata clock frequency of 133 MHz, and a static priority preemptivescheduler, he tbning constraints were met.6 CONCLUSION AND FUTURE WORKlhis paper presented the hardware/software co-design of aindustrial example: the avionics ARINC interface system. Thefirst step of our work was to get a system-level executablespecification, abstracting the implementation details.

Programming in Esterel requires a conceptual approach differentfrom a traditional mono-thread sequential language. Thesynchronous Esterel modules were modified with respect to thePOLIS model used or distributed systems.The POLIS system s convenient for control-dominated systems.The future work will consist of extending the POLIS library withanother microconuoller model with better performance. Thedesign spaceexploration at the system-level could also include thememory. A double port RAM was used by now, without studyingthe effect of o ther types of memory . Finally, the co-synthesis andthe prototyping of a softwa&hardware architecture of the ARINCinterface systemwith the POLIS co-design flow representanotherwork axis.7 ACKNOWLEDGEMENTSWe would like to thank all the membersof the Internet groups ofEsterel and POLIS for their precious help.8[II

121

[31

141

f-51[61171

VI[91

REFERENCESF. Balarin, M. Chiodo, P. Giusto, H. Hsieh, A.Jurecska, L. Lavagno, C. Passerone, A. Sangiovanni-Vincent.&, E. Sentovich, K. Suzuki, et B. Tabham.Hardware-Software Co-Design of Embedded Systems,The POLIS approach Kluwer Academic Publishers,1997.F. B&in, L. Lava8n0, P. Mutthy, and A.Sangiovanni-Vincentelli. Scheduling for EmbeddedReal-Time Systems, IEEE Design & Test ofComputers, pp. 71.82, January 1998G. Berry, G. Gonthier. The Esterel SynchronousProgrammig Language: Design, Semantics,Implementation, Science of Computer ProgrammingVol. 19, NY?, pp. 87.152, 1992.J. Buck, S. Ha, E.A. Lee, and D.G. Masserschmitt.Ptolemy: a framework for simulating and prototypingheterogeneous systems. International Journal ofComputer Simulation, special issue on SimulationSoftware Development, January 1990.R. Ernst. Codesig of Embedded Systems: Status andTrends, IEEE Design & Test of Computers, pp. 45-54,Avrill998R. Ernst. Target Architectures, in W. Wolf and J.Staunstmp Hardware/Software Co-Design: Principlesand Practice, Kluwer Academ ic Publishers, 1997.D. Gajski, F. Vuhid, S. Namyan, et J. Gong.Specification and Design of Embedded Systems,Prentice Hall, 1994.N. Hulhwachs. Synchronous Programming of ReactiveSystems, Khwer Academic Publishers, 1993.N. Halbwachs, P. Caspi, and D. Pilaud. TheSynchronous Dataflow Program ming LanguageLustre. Another look at Real Time Programming,Proceedings of the IEEE, Special Issue, September1991.[lo] J.-M. Laporte . Hardware/software Codesign StudyReport, Annual Conference of European Multimedia,Microprocessor System and ElectronicConunerceMSEC97, Novemberl997.

51


5/5

[ 111P. Le Guernic M. Ix Borgne T. Gauthier and C. LeMaire. Programming Real-Time Applications withSignal. Another look at Real Time Programm ingProceedings of the IEEE Special Issue September1991.

[12]C.L. Liu and J.W. Layland. Scheduling algorithms formultiprogmmming in a hard-real-time environment.Journal of the ACM Vo1.20 N1 pp. 46-61 January1973.

52

HW SW Co Design Avionics Communication Protoco IndustrialCaseStudy

Documents

Transcript of HW SW Co Design Avionics Communication Protoco IndustrialCaseStudy