On the Design of Side-Stick Controllers in Fly-By-Wire
Total Page：16
File Type：pdf, Size：1020Kb
ON THE DESIGN OF SIDESTICK CONTROLLERS IN FLYBYWIRE AIRCRAFT Muy Thomas and Bowen Ormsby University of Glasgow Scotland UK resp ect to some safety requirements Two mo dels of increas Abstract ing complexity are develop ed and analysed using the ISO formal description technique LOTOS Language of Tempo This pap er presents the problem of designing the functional ral Ordering Specication LOTOS is appropriate since b ehaviour of the interaction b etween two sidestick con we are concerned only with relative time rather than with trollers an autopilot and a ightcontrol computer in a real time ybywire aircraft Two mo dels are develop ed using the The rst section gives the informal requirements of the ISO formal description technique LOTOS and analysed us sidesticks controllers and the second section intro duces LO ing rigorous abstract testing techniques TOS The basic design description is given in the third sec Keywords Avionics Design Formal Description Tech tion followed by an analysis of the design Then the design niques LOTOS Pro cess Algebras SafetyCritical Software is extended to include time and this to o is analysed There Sp ecication Testing Verication Validation follows a discussion and our conclusions Intro duction Requirements The reliabili tyofsoftwareinemb edded computer systems is The requirements have b een extracted from a matter of increasing concern particularl y for safetycritical Each pilot has a sidestick and the two sticks are linked systems to the ightcontrol computer Normally b oth sticks are There are no known quantitative metho ds for demon enabled and movements of them pro duce a resp onse which strating high levels of software reliabili ty instead dep ends on the sum of their displacements up to a maximum most approaches to software in safetycritical situations rely of the full deection of one stick So if b oth sticks are moved mainly on assurance based on the evidence pro duced dur forward two degrees the aircraft will b ehave as if one stick ing the software lifecycle Our interest lies in augmenting had b een moved forward four degrees Similarly equal and the preliminary and detailed design stages with mathemati opp osite movements cancel each other out cal mo delling and validation stages our goal is the reduction In an emergency one pilot can override the other pilots of errors and design changes during unit testing after imple controls by pressing a button on hisher stick This button mentation ie by nding the errors before implementation which also acts as the autopilot disengage button causes us we are interested in applying formal metho ds as design Th inputs from the other pilots stick to b e ignored and gives to ols prioritycontrol to the pilot who pressed it If the button is The aerospace industry is an area where software on held down for more than thirty seconds the stick retains pri the whole is extending existing electromechanical systems orityuntil the system is reset bycentralising the disengaged the concerns of control and protection must b e clearly sep stick This override system allows one pilot to take sole con arated and qualied with a high degree of assurance It trol of the aircraft if the other pilot gets into dicultyorif is b ecoming clear from our own exp erience from others in a stick jams the eld and in the aerospace industry eg Amongst many other controls b oth pilots also havean that techniques such as static analysis and validation based autopilot engage button If b oth pilots are in control ie on mathematical mo dels can have an imp ortantroletoplay not overridden and one of them presses this button the au in the design of safetycritical software This is particularly topilot also gains control of the aircraft until one of the pilots the case when analysis addresses the questions of whether presses the autopilot disengage button on hisher sidestick the software satises safety constraints A pilot in control can engage or disengage the autopilot but Here we consider a case study the problem of design a pilot not in control cannot aect the state of the autopilot ing the functional b ehaviour of the interactions b etween two sidestick controllers the autopilot and a ightcontrol com Design Descriptions puter in a ybywire aircraft This is a relevant example since such a conguration is part of the current Airbus Indus The natural language description given ab ove whilst rela trie A Our aim is to develop a mo del from an initial tively clear is still ambiguous and incomplete Further it statement of the requirements to verify that the mo del do es oers no p ossibili ty of rigorously demonstrating that it is a full the requirements and to provide some degree of assur go o d safe proto col that can b e implemented ance that this is a go o d design by analysing the mo del with Our intention is to develop a design description whichis closer to an eventual implementation but abstract enough Funded by University of Glasgow Research Studentship opns nnnnpppp stickpos to allow for rigorous analysis of the essential b ehaviour Succ Pred stickpos stickpos The formal description technique LOTOS is used to eq mo del the design LOTOS is a pro cess algebra similar to stickposstickpos stickpos CCS but with data typ es and multiway synchronisa eqns forall xystickpos tion which allows us to mo del pro cesses that can b e non deterministic andor concurrent with or without synchro endtype nisation Pro cesses can b e parameterised by abstract data A pilots controls consists of the x and y co ordinates of typ e values and suchvalues can b e passed or negotiated a stick the co ordinates are selected with op erations xstick between pro cesses through synchronisation and ystick and the co ordinates are incremented and decre A good intro duction to LOTOS is given in a very mented with op erations xinc xdec etc The op eration brief review of the features of LOTOS we use is as follows central is a predicate to test whether b oth co ordinates are Pro cesses are built up from constant pro cesses events and at the origin Again many of the equations are omitted pro cess op erators Events are atomic indivisi bl e actions In the following P and Q are pro cesses type pilotcontrols is stickpos sorts pcontrols LOTOS Informal description opns mk stickposstickpos pcontrols exit termination xstickystick pcontrols stickpos aP prex P byevent a xincxdec pcontrols pcontrols PQ choice b etween P and Q yincydec pcontrols pcontrols PQ b ecome Q after P terminates central pcontrols bool P Q P in parallel with Q eqns forall xystickpos P l Q P in parallel with Qsynchronisin g ofsort stickpos on events in list l xstickmkxy x exp P if exp holds then b ecome P ystickmkxy y ofsort pcontrols Abstract data typ es are sp ecied in the ACT ONE sub xincmkxy mksuccxy language using manysorted equational logic Values and xdecmkxy mkpredxy pro cesses are combined in twoways lists of values maybe asso ciated with events and pro cesses may b e parameterised ofsort bool byvalues We use two forms of value asso ciation with events centralmkxy x eq and y eq the event oer av oers value v at event a and the event endtype oer avT oers anyvalue of typ e T at event aTwoevents oering equivalentvalues may synchnronise eg atrue can There are distinct values for priority status synchronise with atrueor anotfalse and an event of fer av can synchronise with an event oer avT with type priority is boolean the eect that v is b ound to v when v has typ e T sorts priority The underlying semantics of a LOTOS description is a opns onetwonone priority state transition system rather like a nite state automata eq priority priority bool except that there is no restriction to nite states We use eqns laws which describ e equivalences b etween pro cesses based on the concept of weak bisimulati on b etween transition endtype systems Bisimulati on is socalled b ecause the pro cesses can simulate each other These laws include for example the There are values for autopilot status rule that choice is commutative and that parallel pro cesses type autopilot is boolean renamedby expand into pro cesses involvin g only choice and prex sortnames autopilot for bool For brevity all the events in our descriptions will b e ob opnnames on for true servable This will allow us to omit the usual list of ob off for false servable parameter events in pro cess declarations except endtype in the few cases where the actual and formal events do in deed dier We also intro duce some further trivial abuses The main pro cess comp onents of the system are the two of LOTOS notation for brevity human pilots referred to as pilot and pilot the autopi lot and the ightcontrol computer Basic Design The twohuman pilots b ehaviours are identical up to the names of the events and so the pro cess is parameterised We b egin with a design of the basic system excluding timing Each pilot maymove the stick along one of the four axes constraints forward Fd backward Bk left Lt rightRt depress or Four data typ es are dened to represent the status of release their priority button PandPr resp ectivelyand a stick a pilots controls pcontrols the control priority depress or release their autopilot button AUandAuD priority and the autopilotIntheinterest of brevity resp ectively most of the obvious equations are omitted from these typ es process PilotFdBkLtRtAuAuDPPR A stick can b e in any p osition along an axis from n neg FdBkLtRt ative toppositive with as origin Stick p ositions Pr Au P AuDPilot may b e summed with over and underows rounded up or exit down to