Design of a flight simulator software architecture

Transcription

1 School of Mathematis and System Engineering Reports from MSI - Rapporter från MSI Design of a flight simulator software architecture Karl-Erik Sjöquist April 2002 MSI Växjö University SE VÄXJÖ Report ISSN ISRN VXU/MSI/DA/E/ /--SE

2 Design of a flight simulator software architecture Karl-Erik Sjöquist Master Thesis School of Mathematics and Systems Engineering, Växjö University Supervisors: Göran Ancker, Saab Jan Wallenberg, Saab Examiner: Ulf Cederling, Växjö University VXU/MSI/DA/E/ /--SE April 2002

3

4 Abstract Simulation is an important tool used in many different areas. One area is the aircraft industry which uses simulations to e.g. develop/test different systems and train pilots, during an aircraft s whole life cycle. New more powerful computers have made it possible to build more and more advanced simulators, that allows more complicated simulations. The more advanced the simulators gets, the more complex the simulator software gets. To investigate how to handle this increasing software complexity is the purpose of this thesis. This thesis investigates several software architectures, including both theoretical architectures and architectures used in existing simulators. The aim of this thesis is to develop a software architecture for both a real-time executive and data distribution, used in a flight simulator. The architecture should be able to handle the increasing software complexity and still make it possible to develop more complex simulations. The architecture should also support a high degree of reuse, be possible to use when improving current simulators and to be a base from which new simulators can be derived. i

5 ii

6 Acknowledgements This thesis was written in cooperation with the department FDM, Future Products, Modelling and simulation, at Saab in Linköping, and is the final part of my studies to a master of science in computer science at Växjö University. The thesis was written during the period June 2000 to December Many people have been involved in the work and I would like to thank them all for their cooperation. I would especially like to thank Göran Ancker and Jan Wallenberg, who have been my supervisors during the work, for all their help trying to keep me working in the right direction and for their patient reading. A special thanks also to Björn Lindqvist, Arne Mårtensson and Björn Olofsson for their help when I was trying to figure out how the simulators at Saab are designed. iii

7 iv

8 Guide for the reader This thesis is divided into tree main parts. The first part, chapter 1 to chapter 4 is a more theoretical part where the different areas used in the rest of the thesis are introduced. This includes an brief introduction to flight simulation and software architecture. Chapter 3 and 4 contains the results from the research on current simulator architectures. The research includes several different simulators develop at Saab, one simulator develop Lockheed Martin/HiQ Approve and two architectures, one developed by Boeing and one at the software engineering institute (SEI), based on structural modelling. The second part contains the architecture development. It includes requirement analyses, i.e. collecting the requirements which the architecture must fulfill. These requirements are the base from which the architecture is developed in chapter 6, 7 and 8. The third and last part, chapter 9, is the conclusions. In this section an evaluation of the architecture is made to see if the architecture fulfill the initial requirements. v

9 vi

10 Table of contents 1 Background Different simulators This thesis Methodology Software architecture What is software architecture? Current software architectures PMSIM/SYSIM Data distribution and executive FMS/MMT Object Subsystem Sequencer Structural modelling Air Vehicle Structural Model The component Subsystem controller Periodic sequencer Event handler Timeline synchronizer Domain Architecture for Reuse in Training Systems Components Subsystem controller Segment executive Module executive Virtual network FMV/HiQ Approve/SAAB Components Subsystems Executive Object orientation Summary AVSM and DARTS FMV/HiQ Approve/SAAB Object orientation vs. structural modeling Requirements Hardware architecture Suggested software architecture Executive level requirements General requirements Executive requirements vii

11 5.3.3 Subsystem requirements Recording requirements The data distribution system Existing solutions Global memory Buffered shared memory A new approach The subsystem architecture Parameter passing Subsystem controller The subsystem database Data distribution between subsystems The executive responsibilities Data distribution consistency Double buffering Communication with other computers Recording Support for recording Recording details The circular buffer The control unit Writing to the hard disc File format Building a system System configuration The database Database router Database access controller Subsystem data The executive Executive requirements The executive architecture Extension to multiple processor cards Increasing the performance Conclusions Results Architecture evaluation Future work References Simulation articles Papers Books, computer science viii

12 10.4 Other books Internet sites Glossary ix

13 x

14 List of figures Figure 3.1 PMSIM/SYSIM architecture Figure 3.2 Software structure in the FMS/MMT simulator Figure 3.3 Frame phases Figure 4.1 The AVSM architecture Figure 4.2 The component element Figure 4.3 The subsystem controller Figure 4.4 The periodic sequencer Figure 4.5 The event handler Figure 4.6 The timeline synchronizer Figure 4.7 Configuration of the DARTS architecture Figure 4.8 The architecture proposed by FMV/HiQ Approve/SAAB.. 22 Figure 4.9 The object orientation version of hierarchic structures Figure 5.1 Hardware architecture Figure 5.2 Software architecture Figure 6.1 Global memory configuration Figure 6.2 Buffered global memory Figure 6.3 Basic interaction Figure 6.4 Subsystem decomposition Figure 6.5 Model processing Figure 6.6 Subsystem with database extension Figure 6.7 The executive data processing Figure 6.8 the variable table Figure 6.9 The complete data distribution system Figure 6.10 Sharing with most recent value Figure 6.11 Solution to sharing with most recent value Figure 6.12 Double buffering problems Figure 6.13 Variable reference list Figure 6.14 System using several double buffering buffers Figure 6.15 Database extension Figure 7.1 Parts involved in the recording process Figure 7.2 The internal decomposition of the record system Figure 7.3 The circular buffer Figure 7.4 Writing data to the hard disc Figure 8.1 System configuration Figure 8.2 Database decomposition Figure 8.3 The executive architecture Figure 8.4 The INS reset signal xi

15 xii

16 1. Background 1 Background Constructing an accurate aircraft simulator is not an easy task. As the aircraft continue to grow in complexity so does the simulation systems. For example the B2 simulator, built by Boeing, contains almost two million lines of Ada code. To create those large software simulation systems it has always been of great interest to write software which is fast, reliable and easy to maintain. Fast execution is necessary to make the simulators run in real-time. Reliability is needed, e.g. if the simulator is used for testing new components which will fly in the real aircraft. The maintenance of the simulator is very important because of its very long life time. During the life time the aircraft will certainly be developed, which must be reflected in the simulator software/hardware. To make this possible the simulator must be easy to modify. The three non functional requirements, fast execution, reliability and maintainability, are not easy to combine and several approaches have been used to try to find a good mixture of them. When digital aircraft simulators first became possible, around 1960[12], computer hardware was very expensive and not very fast. One problem with running a real-time simulator on slow computers, is that most of the execution time is needed to complete the calculations in time, to meet the real-time requirements. In the earliest simulators the need for fast execution and the lack of structure in the programming languages being employed, very often led to simulator software that was very dependent on the hardware it was running on. This hardware dependence made the simulator software hard to maintain and hard to move from one computer to another. The lack of structure also made the software very hard to change and maintain as the aircraft was developed. One approach to increase the maintainability, without losing too much computational power in structuring over head, was to use some kind of coding standard. One such standard, used by SAAB in the current simulators, is that all called simulator model functions starts with a read phase, where all data the function needs to execute its task are read from the common memory area. The function continues with the execution phase where it executes all calculations. Finally, the write phase is entered where the results are written to common memory area. Standards like this made the simulators less sensible and more reliable, but there are still problems with maintenance and the introduction of new functionality. When the computer hardware got faster it became possible to build software structures which were less dependent of hardware it was running on. Many efforts were made and two similar architectures based on structural modeling (see chapter 4), were developed, the Air Vehicle Structure Model (AVMS), developed at Software Engineering Institute (SEI) [5], and the Domain Architecture for Reuse in Training Systems (DARTS) [1]. Instead of using old fashion function calls and parameter passing as in AVSM and DARTS object orientation is becoming more and more popular. The third approach is to take advantage of the very powerful features of object orientation when developing new simulator architectures. The object oriented method has been possible with the development of programming languages such as Ada95 and C Background 1

17 1. Background 1.1 Different simulators Different simulations have different requirements on the simulators. Simulations have a very broad spectrum, from simulating a single component to a complete tactical simulation including several aircraft. To be able to meet all those simulator requirements SAAB have built several different simulators among them: SYSIM, STYRSIM, PMSIM and TACSI. All four simulators have been built for different purposes and to meet different requirements. SYSIM (there are two almost identical SYSIM simulators) has been constructed to be an as accurate system simulator as possible. It is built with the same real hardware/software that flies in the real aircraft. STYRSIM is mainly used for flight control system development. It is an development simulator in which all flight control first is tested before it passed to SYSIM for further testing and integration with the real aircraft. STYRSIM does not contain any real hardware and is there for completely dependent on software models. PMSIM is constructed to simulate the pilot interactions with the aircraft. PMSIM does not contain any real hardware (except for the hardware required by the pilot to fly the simulator) instead all simulator models are written in software [3]. TACSI is an abbreviation for tactical air combat simulator and is used to build and simulate combat situations. It is possible to include several computer generated aircraft, both friendly and hostile, which follows predefined tactics and allow the human pilot to train combat situations in a safe environment [4]. Although the simulators have different purposes the basic simulation models, such as aircraft aerodynamic and hydraulic models are shared among many simulators. The problem is that there is no easy way to move a model from one simulator to another due to different software architectures Background

18 1. Background 1.2 This thesis The purpose of this thesis is to investigate how to decompose the software in a modern flight simulator and to develop a software architecture which is possible to use in both current and future flight simulators. The architecture shall include a description of the software decomposition and how these parts are exchanging data Methodology The architecture is developed by studying one theoretical flight simulator architecture, one architecture designed and used by Boeing and the architectures used in the current simulators used in the JAS project. The results from the investigation part, chapter 3 and 4, will be the base from which the new architecture is developed. The technics found in chapter 3 and 4 will be analyzed to see if it is possible to use them in the new architecture. Chapter 5 contains an investigation of which requirements, both the current and future simulators, have and will have. The goal is that, with experience from the study of earlier simulators and the requirements of the current and future simulators at SAAB, it should be possible to develop a software architecture, that will meet both current and future demands of the simulator software. 1. Background 3

19 4 1. Background 1. Background

20 2. Software architecture 2 Software architecture In the early days of computing the main focus was on the computer hardware. Computer software was very limited due to week hardware. The hardware limits kept the software systems small, small enough to be developed by just a few people. These people knew exactly what the entire software system was doing and how all parts of the system interacted. When computer hardware became more powerful and less limiting, it became possible to write more powerful software containing more functionality. This new powerful software required more people to work together in the same project. The software systems grow and more and more people were involved in a single software project. This increase in the size of software systems became more and more difficult to handle and to solve the problem new theories about how to write software were needed. One of the theories that was invented was software architecture. 2.1 What is software architecture? Software architecture is the key word and may be the answer to several problems concerning the never ending increase in size and complexity of modern software systems, but what is software architecture? There is not one simple answer to that question, different people have different definitions. However, all definitions have several things in common, which make it possible to identify some properties a software architecture must have. A software architecture is as important for the success of a software development project as it is for the success of a building project. The architecture is used in very much the same way in both areas. A bad architecture may lead to the collapse of a building or in the software case, the failure of fulfiling the initial requirements. Even if there are many similarities between the software architecture and the more traditional building architecture there are also several differences which make the comparison less meaning full. One such difference is that it is not possible to make major architectural changes in the building architecture, e.g. switching from a wooden house to a brick house, once the constructing of the building has begun, but in the software case some minor changes are possible to make, even if the project has been under development for some time. Software architecture is not concerned with the low level implementation details of a software system, instead it is utilized to describe the system at a high, abstract level. Words often used together with software architecture is: structure, modular decomposing, communication, scalability and evolution. 2. Software architecture 5

21 2. Software architecture Structuring, is used to decompose the system into sub-systems, where a subsystem is an independent software unit. Modular decomposition is the activity which decompose the previously defined subsystems into smaller modules. It also defines the communications among the different identified modules. Communication. There is a large need for communication among both the modules and the subsystem. Communication is a very important part of the architecture because it may affect the whole efficiency in the system. Scalability and evolution. The architecture is preferred to be designed in such a way that it is possible to increase the functionality and add new subsystems and modules over the whole life time of the product. The longer the life time of the system is, the more importance this property gets. As previously mentioned there is yet no perfect definition of software architecture, but several attempts have been made to find a good definition. One definition, made by Garlan and Shaw [9], says that: a software architecture defines the system in terms of computational components and interactions among those components. This is a decent definition and includes the properties we wanted for the definition of software architecture Software architecture

22 3. Current software architectures 3 Current software architectures The software architecture used in three different simulators have been studied. The simulators have similar architectures, but because of the different purposes of the simulators there are differences. The studied simulators are PMSIM, SYSIM and the Full Mission Simulator/Multi Mission Trainer (FMS/MMT) simulator. 3.1 PMSIM/SYSIM Both PMSIM and SYSIM are constructed at SAAB. They have similar architectures but are used for different purposes. The purpose of PMSIM is to be a simulator where the development of the flight control system, the man-machine interface, airborne sensor system and the weapon system is possible. PMSIM is the most general simulator at SAAB and can be used to simulate several different generic aircraft, e.g both JAS39 Gripen and JA37 Viggen. SYSIM is used for system development, including testing of both hardware and software which will fly in the real aircraft. Because of the real hardware in SYSIM timing is a very important property. This is one of the reasons why SYSIM is a simulator containing both software and hardware models. Hardware models are used when the timing in the corresponding software models are not reliable enough. PMSIM does not contain any aircraft specific hardware with critical time requirements, instead all systems are simulated in pure software Data distribution and executive In the current simulator architecture all models are gathered regarding to how often they need to be executed. The simulator executive consists of several scheduler called dirigenter, which are responsible for calling the correct models at correct times. The base frequency in the simulators is 60Hz, which means that each model may be executed every 1/60s (16.7 ms), and must of course complete its task in less then 16.7ms. In SYSIM the base frequency is coming from one of the real aircraft hardware devices. This signal is also used to synchronize the software models in the simulator with the hardware devices. In PMSIM, due to the absence of the real aircraft hardware devices used in SYSIM, the 60Hz frequency is input to the simulator from an external clock circuit. All models do not have to be updated every 16.7ms and to save execution time the 60Hz base frequency is divided into lower frequencies. Each frequency (1, 7.5, 15, 30 and 60Hz) is assigned to its own scheduler. The scheduler is holding information about in which order to execute the models. The execution order is critical to be able to guarantee that the models are executing with the correct input. Wrong input may occur because different models are updating variables without restrictions. 3. Current software architectures 7

23 3. Current software architectures DATAPOOL is a shared memory used for sharing data among different processors and different processes. The problem of guaranteeing data consistency is derived from this global memory. Each model is allowed to read and write as it wishes in the shared memory. The data consistency problem arises when one model writes to a variable in DATAPOOL before other models using the same variable have read its old value. If this is the case the reading model gets a value which may lead to wrong output and cause errors in the simulation. In figure 3.1 the PMSIM/SYSIM architecture has been depicted. The figure does only contain two scheduler, but in the real simulator there can be several, at least one for each frequency. All scheduler are connected in the same way. The block called DATIN in the figure is functionality to control the simulator synchronization, recording of variables during simulation, loading new simulator configurations etc. Clock DATIN Executive 60Hz Scheduler 30Hz Scheduler Model Model Model Model Model... Model DATAPOOL/Shared memory Figure 3.1 PMSIM/SYSIM architecture. This figure does not show all the details of the simulator architecture but include the basics about the executive and data distribution system Current software architectures

24 3. Current software architectures 3.2 FMS/MMT The Full Mission Simulator /Multi Mission Trainer (FMS/MMT) simulator is mainly used for training and education of pilots in the swedish air force. The computer system in the simulator consists of several processors hosted in several different computers. Communication between the computers are accomplished in two ways: with shared memory and through ethernet networks. All computers, except the instructor/operator station (IOS) which is using ethernet to communicate with the simulator kernel, is communicating through a common memory area. The software structure in the simulator is depicted in figure 3.2. Figure 3.2 Software structure in the FMS/MMT simulator. Event Handler Training controller Sequencer Subsystem Subsystem Subsystem Object Object Object Object The object is the lowest part of the architecture. Objects are intended to simulate basic components in the aircraft. The object is not allowed to read or write shared data directly. All data the object needs to execute its calculations must be sent to it through parameters in function calls. The results the object produces are sent to the subsystem to which it belong through parameters and function return values. The object should at least provide two functions: initialize and update. The initialize function is used to put the object in a well defined state. The update function is used to instruct the component to calculate results for the next simulation cycle. 3. Current software architectures 9

25 3. Current software architectures Subsystem Each object belongs to a subsystem. If several objects are used to accomplish a specific task they are placed in the same subsystem. Inside the subsystem there is an element called training controller. The training controller is utilized to call the objects in the correct order. If the subsystem uses several processors the training controller is also responsible for synchronization among them. A training controller is called by the sequencer with one of the frequencies 60, 30, 15, 7.5 or 1Hz. This frequency is also the frequency by which synchronization with other processors are made. The training controller time is dived into frames. A frame is one call to the subsystem, figure 3.3 shows the three phases in each frame. The subsystem contains a memory area called local export area in which the results are temporary stored before they are written to the global export areas. All subsystems have export areas where other subsystems may read data. The subsystem frame is divided into three phases, the export phase, the update phase and the event phase, see figure 3.3 below. To prevent disturbance between processors using the same variables, results produced during update phase are placed in the local memory area. During the export phase the results, which are of interest for other processors are written to the global memory area. The event phase is used for checking if any events have occurred. In this architecture events are handled by polling and not by exceptions as in the AVSM and DARTS architecture described later. Export Update Event CPU A CPU B CPU C Sequencer 1/60s Figure 3.3 Frame phases. This is the component that controls the whole simulator execution. It is responsible for calling the correct subsystem with specified frequencies and to call the subsystems in a correct order Current software architectures

26 4. Structural modelling 4 Structural modelling Structural modelling is one approach to try to make a very complex system, such as a modern aircraft simulator, easier to handle. The idea behind structural modelling is to divide the complex system into several different parts. Those parts are then grouped in a hierarchic structure. Two different architecture styles based on structural modelling for aircraft simulators have been studied, the Air Vehicle Structural Model (AVSM), developed by SEI in 1993 [5], and the Domain Architecture for Reuse in Training Systems (DARTS) [1]. The DARTS architecture was developed by Boeing. Both architecture styles have many things in common, but also a few important differences. When describing the structural models several terms are used, terms which are common in the two architectures. Four terms are of special interest. Both architectures can be divided into levels. The two levels defined are the executive level and the application level. The parts which the system is divided into are called structural elements. Both AVSM and DARTS consists of five structural elements. Operations are functions that are possible to call in the structural elements. Operation can be Update which is called by the executive once every simulation cycle. Data flow is how data is passed between the structural elements. Control flow is the same thing but instead of data, messages are passed or function calls are made to communicate between structural elements. Structural modelling may be seen as an attempt to use object orientation methodology on a non object oriented system. The decomposing of the system is made with function in mind. When the decomposing is made, already existing subsystems in the aircraft are identified and the models describing that system are kept together. By keeping the models describing the same system together the logical structure can be maintained which often leads to a better understanding of the simulator software. 4. Structural modelling 11

27 4. Structural modelling 4.1 Air Vehicle Structural Model The Air Vehicle Structural Model (AVSM) [5] is defined as a reusable collection of classes of differing levels of abstraction providing the basis from which the flight simulator software is derived [5]. The AVSM is designed to run as a single process on a single processor. To increase the speed of the calculations, AVSM can be modified to support several processors and several processes. If multi-processors are used each processor contains an instance of AVSM. The only communication in a multi processor environment is between the cyclic executives (see figure 4.6) through distributed shared memory. The AVSM is divided into two different levels, the executive level and the application level, see figure figure 4.1. The executive level is responsible for scheduling the models, the interfaces to the simulator operator and the data integrity while the actual models the executive schedules belongs to the application level. The following five structural elements have been defined in the AVSM architecture. AVSM consists of the following five structural elements. Component Subsystem controller Periodic sequencer Event handler Timeline synchronizer All structural elements will be discussed separately. The application level of the architecture consists of the first two elements and the remaining three elements are part of the executive. The relations among the elements are shown in figure Structural modelling

28 4. Structural modelling Timeline synchronizer Periodic Sequencer Event Handler Executive level Subsystem Controller Application level Component Data flow Control flow Figure 4.1 The AVSM architecture. The arrows in the figure above shows how the different elements are allowed to send data to each other and how they are allowed to communicate. The arrows with a full line are data passing channels, e.g. the event handler may send data to the subsystem controller. The dashed line is a communication channel through which communication is possible, e.g. the subsystem controller is allowed to send instructions to the component but the component can not send instructions to the subsystem controller. Lines with two arrows indicates that data/communication transfers are allowed in both directions. The data line between the subsystem controller and the component has arrows in both ends, which means that the data is allowed to flow in both directions. The subsystem can contain several components, see chapter for details about component communication. 4. Structural modelling 13

29 4. Structural modelling The component The real aircraft can be divided into several different subsystems, such as flight control system and hydraulics. The same decomposition is possible to make in the AVSM architecture. As in the real aircraft, a subsystem in AVSM contains at least one component. Components in both the real aircraft and AVSM are small parts such as a pump in the hydraulic system. The component element in AVSM is used to describes the behavior of the real part with a computer model containing an encapsulated set of variables. The state of the component can be changed in two different ways, periodic and aperiodic. Periodic operations are operations that are scheduled by the periodic sequencer (see chapter 4.1.3), and are part of the normal simulator operation. The aperiodic operations are events which happens irregular, e.g. fault introduction. All data a component needs is passed to it when one of its functions is requested. This makes the component isolated from the rest of the system, which is a very good property when reuse of software is desired. An overview of the component is shown in figure 4.2 below. periodic operations aperiodic operations Component Component state data Figure 4.2 The component element. Figure 4.2 is a more detailed description of the component part in figure 4.1. The arrows on top on the component are the same arrows as in figure 4.1. When several components are gathered in a subsystem they are not allowed to communicate directly but must send all their communication through the subsystem controller Structural modelling

30 4. Structural modelling Subsystem controller Components are, as already mentioned, gathered in groups called subsystems. Subsystems are handled by an element called subsystem controller in AVSM. The subsystem controller acts as an interface between the components and the rest of the system. Like the components, the state of a subsystem controller can be altered both through periodic and aperiodic operations. Periodic operation are sent to the subsystem controller from the periodic sequencer. Periodic operation are operations which occurs once every cycle (see timeline synchronizer) in the simulation. A periodic operation may be the update operation which causes the subsystem to compute a new state. Reading and/or writing to the common export areas are also possible periodic operations. Events are often caused by the simulator operator. Events are operations which are not scheduled in every simulation cycle. They are passed from the event handler (see figure 4.1) to the subsystem controller as aperiodic operations. The aperiodic operations include hold_parameter and configure. The hold_parameter operation is used by the simulator operator to freeze the value of a variable for later investigation. The configure parameter is used to set a subsystem into a desired state. Subsystems do not communicate with other subsystem through function calls and parameters passing, instead they use export areas (see figure 4.3). Export areas are memory areas which are shared by all subsystem controllers in the whole system. A variable in the export area may only have one writer but many readers. The schematic overview of the complete subsystem controller is shown in figure 4.3. The arrows in figure 4.3 shows the connections to the component, periodic sequencer and event handler, see figure 4.1 for a detailed description of the relations among the elements. periodic operations aperiodic operations Export area Subsystem controller Simulation state data Export area Figure 4.3 The subsystem controller. 4. Structural modelling 15

31 4. Structural modelling Periodic sequencer The periodic sequencer is the element which is responsible for all periodic processing in the system. The periodic sequencer is holding information about the computational order of the subsystems. The scheduling information is kept in a scheduling table inside the periodic sequencer. The scheduling table is precomputed and based on a worst case situation. The periodic sequencer is also responsible for controlling the access to the export areas, when the subsystems needs to read and/or write data in the shared memory. Figure 4.4 below shows the periodic sequencer. The communication channels (shown as dashed arrows in figure 4.4 below) shows that the periodic sequencer is given instructions from the timeline synchronizer. The periodic sequencer does not contain any time information about when to execute the subsystems it is scheduling. All timing information the periodic sequencer needs is sent from the timeline sequencer (see for further details). This is indicated by the top right arrow in the figure. The top left arrow in the figure below is the communication channel used to give the periodic sequencer access to the export areas. The periodic sequence is allowed to send instructions to the subsystem controller, this is indicated by the dashed arrow at the bottom of the figure. The last arrow indicates that data transfer is possible in both directions between the subsystem controller and the periodic sequencer. In the figure there is an item labeled simulator state which is in some way connected to the event handler. The event handler may, when e.g. on command from the instructor operator station (IOS), stop the simulation process. To give information to the rest of the simulator to stop, the event handler changes the state of the simulator. This state is read by the periodic sequencer. Stop is just one among several possible states, other may be e.g. configure and stabilize. data moves periodic processing Periodic sequencer Simulator state Scheduling table Figure 4.4 The periodic sequencer Structural modelling

32 4. Structural modelling Event handler The event handler (see figure 4.5) object is mainly used for interaction with the IOS. When an event, such as hold or subsystem malfunction, is generated by the IOS. The event is put in an event queue in the event handler (see figure 4.5). The event handler uses the dispatching table to schedule the subsystems affected by a special event. Information about which subsystem that are affected by the event, is passed to the event handler from the IOS function, that caused the event. The event handler must communicate with the periodic sequencer to inform the rest of the simulator of the state resulting from the event. The arrows in figure 4.5 indicate that the event handler is allowed to send both data and commands to the subsystems affected by the event being processed. To take the correct action when an event occurs the event handler must be able to read the state of the simulator. This is done with the box marked simulator state. The arrow at the top of figure 4.5 is the synchronization channel to timeline synchronizer. This is very important to prevent the event handler to execute the event within an on going execution of a cycle. event processing Simulator state Event handler Dispatching table Event queue Figure 4.5 The event handler. 4. Structural modelling 17

33 4. Structural modelling Timeline synchronizer The fifth element in the AVSM architecture is the element which is controlling the timing in the whole simulator. The element is called timeline synchronizer, and is a classic cyclic executive. The time each processor provides is divided into intervals, called cyclic frames. The timeline synchronizer has three main responsibilities. To synchronize the start of frames and periods within frames, with other processes. To initiate synchronized data exchange between subsystem controllers export areas. To call the periodic sequencer and the event handler at appropriate times. In a system with multiple processors one timeline synchronizer is taking the role as the main synchronizer, and is used for synchronization among the other timeline synchronizers. The main timeline synchronizer runs with the highest frame rate of all processes. The timeline synchronizer is depicted in figure 4.6. Figure 4.6 shows how a cycle in the simulator is instructed. The cycle begins with a data access followed by the periodic operations in the subsystems and finally events from the IOS is handled. The dashed arrows indicates the communication with both the periodic sequencer and the event handler. If multiprocessors are used the main timeline synchronizer uses an interprocess communication mechanism to synchronize the simulator execution. Data access Timeline synchronizer Cyclic frame Periodic processing Event processing Interprocess synchronisation Figure 4.6 The timeline synchronizer Structural modelling

34 4. Structural modelling 4.2 Domain Architecture for Reuse in Training Systems The Domain Architecture for Reuse in Training Systems (DARTS) [1] was developed by Boeing independent of the AVSM, but both architectures have a lot of things in common. One of the goals with DARTS was to exploit the possibility of reuse in structural modelling. DARTS consists of five structural elements which have many things in common with the structural elements in the AVSM, but there are some major important differences. The elements defined in the DARTS architecture are: Component Subsystem controller Virtual network (VNET) Model executive Segment executive A possible configuration of the DARTS architecture is shown in figure 4.7. The figure does also show how data is distributed in the architecture. The arrows in figure 4.7 describes possible data and communication ways within the architecture. Module executive OS operations Application services Segment executive Segment executive Virtual network Subsystem controller Subsystem controller Timer Data flow Control flow Component Component Components Figure 4.7 Configuration of the DARTS architecture Components in the DARTS architecture has almost exactly the same purpose as the components in the AVSM architecture. That is, in the component all detailed information 4. Structural modelling 19

35 4. Structural modelling about a specific object in the simulated vehicle is hidden. The component is an abstraction which allows a specialist to write the component model and encapsulate the functionality before it is inserted into the simulator. The encapsulation increases the possibility of reusing the component. The component gets the data it needs, as in the AVSM architecture, from function calls rather than reading in a common memory area. This helps to decreases the dependency among objects and make them easier to reuse. Every component must check the input to make sure it is reasonable. This is done to make the components more reliable, and make it easier to find possible errors in the simulator. Each function should contain an initialize function. Once the component has been initialized it is the components responsible to put it self into a safe state. After the initializing the component can be called even if no data has been sent to it, which makes the computational order less important Subsystem controller The subsystem controller is almost identical in both the AVSM and the DARTS architecture. The difference is that in DARTS the data doesn t flow to a shared export area, but to the segment executive which puts the data on to the VNET (described in chapter 4.2.5). The subsystem controller is used to provide a common interface for all components. A subsystem may consist of several components Segment executive The segment executive gathers components and subsystem that have something in common. Components and subsystems which frequently exchanges data are often placed in the same segment.the segment executive does also contain scheduling tables with information about the computational order among the subsystems in a specific model. This encapsulation make segments a very good candidate for reusing. The segment executive contains functionality which provides the components and subsystems with an interface for communicating, over the VNET. The VNET is necessary for communicating with other components and subsystems located in other segments Structural modelling

36 4. Structural modelling Module executive The task assigned to the model executive is to execute computational models. It is also responsible for assigning resources, such as storage and displays etc. All functionality possible to run on the computer is located in a module, including operating system functions, interrupts and process handling. If the simulation system is running on a multiple processor hardware the module executive is responsible for the necessary communication between the processors. The module executive contains information about how to execute the segment executives. How the segment executives are executed depends on the system. It may be done by function calls or activating a sleeping process, depending on the segment executive implementation Virtual network The virtual network (VNET) is the biggest difference between AVSM and DARTS. It has no direct translation between the two architectures. The VNET is the main structure used for communication among different segments. Each message is defined as an Ada specification type. To make the communication more reliable DARTS defines possible senders and receivers for each message. To make components less dependent of the hardware they are running on, the VNET provides some simple operations to send messages between elements. The operations completely hides the implementations, which allows the components to be moved from one platform to another, without knowing the exact implementation of the VNET. 4. Structural modelling 21

37 4. Structural modelling 4.3 FMV/HiQ Approve/SAAB The architecture proposed by FMV/HiQ Approve/SAAB [2] is based on the AVSM and the FMS/MMT architectures described earlier. Some modifications had to be made to make the architectures more suitable for the already existing simulators at SAAB. Only three of the five elements in the previous architectures are used in SAAB s architecture, the component, the subsystem and the executive. The executive element is a combination of the segment executive and the model executive in the DARTS architecture. When FMV/HiQ Approve/SAAB developed their architecture, there was no time to make a description of the executive level. Common things with the two other architectures are that it has the component elements containing low level functionality and the subsystem which is used to group components into more reusable elements. The communication between elements have the same principle as the two other architectures. Two Components are allowed to communicate directly with each other if and only if they are in the same subsystem. If a component in one subsystem wants to communicate with a component in another subsystem, the component must send its data through the subsystem controller. The subsystem passes the data to the data distribution unit which forwards the data to correct subsystem. The subsystems finally passes the data to the correct component. Exactly how this data distribution functionality should be implemented will be investigated in chapter 6. Figure 4.8, gives an schematic overview of this architecture. A more detailed description of the architecture will be given in chapter 5. Control flow Data flow Executive Subsystem Subsystem Component Component Component Figure 4.8 The architecture proposed by FMV/HiQ Approve/SAAB Structural modelling

38 4. Structural modelling Components The main goal with components is to encapsulate functionality and to make the software models more reusable. Components may be one of two types, software models or independently executing models. All components have a common interface, which makes it possible for subsystems to call a component, without knowing exactly what the component does. Components have several constraints, they must be called from a subsystem. not contain any functionality related to the executive or data distribution. be called with parameters. have a common interface which the subsystem is able to use. All systems are not possible to simulate with just software, there are several reasons for this, e.g. the timing requirements are too high or it is a requirement to use real hardware systems in the simulator. It is not possible to use a standard interface for all hardware components. To make the hardware models fit in to simulator architecture, a specialized subsystem is created. This subsystem provides the rest of the system with the common interface to hardware model, needed for communication and data distribution Subsystems A subsystem is an abstraction for a real system in the aircraft. Each subsystem contains at least one component which models the real system. The subsystems are scheduled by the executive, which is also responsible for activating the subsystems at correct times. Subsystems are also responsible for the communication with the executive and data distribution among components Executiv The executive has the same responsibilities as the executive level in AVSM. It is responsible for calling the subsystems either with an even cyclic frequency or by events. 4. Structural modelling 23