a hardware-in-the-loop simulation environment for ...

A HARDWARE-IN-THE-LOOP SIMULATION ENVIRONMENT FOR INTEGRATION OF DISTRIBUTED AVIONICS SYSTEMS 1 A.G. Bakhmurov, V.V. Balashov, M.V. Chistolinov, R.L. Smeliansky, D.Yu. Volkanov, N.V. Youshchenko, Lomonosov Moscow State University, Dept. of Computational Mathematics and Cybernetics, Laboratory of Computer Systems e-mail: {hbd,bahmurov,mike,smel,dimawolf,yoush}@lvk.cs.msu.su In this paper we present a technology for integration of distributed real-time embedded systems (RTES) based on hardware-in-the loop simulation. The environment to support this technology is described. This environment also enables simulation-based development of RTES software and evaluation of RTES architecture on early stages of RTES development. Actual and planned application of this environment includes (but is not limited to) the development and integration of real-time avionics (RTA) systems. 1 INTRODUCTION Modern onboard distributed real-time embedded systems (RTES) consist of multiple devices connected by a network of data transfer channels. Each RTES device runs a specific mix of application and system software tasks. On early stages of RTES development, hardware and software components of RTES devices are developed concurrently. On these stages, availability of hardware prototypes for the devices is limited, i.e. prototypes are available only for some of the devices or not available at all. This leads to a variety of problems for RTES developers. First, unavailability of device’s hardware or its prototype limits the possibility of assessing realtime characteristics of the device’s software operation, and there is a need for exploration of these characteristics without access to hardware prototypes. Besides a standard real-time OS, the RTES devices’ system software includes specialized tasks that implement the logic of data exchange through onboard channels, including processing of exchange errors. To activate and test these tasks without involving prototypes of other interacting devices, an external stimulation for the tasks is needed that imitates data exchange through channels. On later phases of RTES development, the number of devices’ prototypes is usually enough for construction of a single prototype of the whole RTES, on which only one session of system-wide software integration can be performed at a time. Different issues in interaction between software tasks on different devices, including system tasks responsible for data exchange, require several concurrent debug sessions. There is a need for performing such sessions independently of the hardware RTES prototype. If the RTES is intended for small batch production, there is often the case that the only complete and integrated hardware prototype is moved to in-site testing and becomes unavailable for the development and integration teams. This makes difficult to reproduce off-site the issues that come out during the in-site testing. In this paper we present the DYANA simulation environment which addresses the needs listed above by supporting a process of simulation model-based RTES software development. This process includes development of simulation models for the devices that incorporate source code of application software and custom system software of the devices (the code must be written in C according to defined requirements). Models of devices, along with built-in simulation models of data exchange channels, are involved in purely-software simulation of the whole RTES aimed at discovering the issues in devices’ software operation and in inter-device interaction. During the simulation, real-time characteristics of the software included in the models are estimated. When hardware prototypes for This work is partly supported financially by the Russian Foundation for Basic Research under grants 07-01-00237, 09-0708026. 1

some devices become available, they can be included in HITL simulation together with models of devices that are unavailable in hardware. Source code of device’s application and system tasks is transferred to the hardware prototype of the device. When the device is moved to in-site testing, it can be replaced by its model. On the phase of RTES integration, when some of the RTES devices become available in hardware, following problems arise that require tool support: 1) verification of compliance of the RTES devices to the technical specification, including requirements to data exchange through external interfaces of the devices; 2) validation of devices’ communications through onboard data transfer network; 3) integrated testing and debugging of RTES software, including distributed software on several devices; 4) dependability assessment of the RTES architecture, including estimation of throughput margin on data transfer channels and resilience of RTES hardware and software to data exchange failures; 5) scheduling of data exchange through channels and validation of the constructed schedules. Development of RTES devices and of the RTES itself is a distributed process performed by several teams located in different companies. Devices become ready for integration in different points of time. To meet the deadlines for RTES development, the integration operations should begin in advance, when the RTES devices are not completed. DYANA simulation environment provides tools for hardware-in-the-loop (HITL) simulation of RTES that enables incremental RTES integration, including solving of problems 1-5, while gradually building-up the RTES according to the schedule of incoming devices. The DYANA simulation environment is developed in the Computer Systems Laboratory (CS Lab) of Computational Mathematics and Cybernetics department of the Moscow State University. For previous work on DYANA, see [2,23]. The rest of the paper is organized as follows. Section 2 presents an overview of several existing HITL simulation environments and estimates the degree of support of simulation-based development and integration of RTES by these environments. Section 3 introduces the DYANA simulation environment and its capabilities for simulation model-based development and architecture evaluation of RTES. Section 4 presents a hardware/software environment for HITL simulation which is based on DYANA. Section 5 describes a HITL simulation-assisted process of RTES integration involving this environment. In the last section, future directions of work are proposed. 2. RELATED WORK In this section we present several examples of existing HITL simulation environments and assess their degree of support for the following steps of simulation model-based development and integration of RTES: 1) purely-software simulation of RTES devices, involving real source code of the device’s application and system software tasks, and reproducing real-time behaviour of software tasks; 2) purely-software simulation of RTES as a whole, including simulation of data exchange through onboard channels; 3) HITL simulation, involving a mix of real RTES devices and models of RTES devices, interacting through real onboard channels. eDRIVEsim toolset [11,16] is designed to conduct controller testing and HITL simulation of electric and power electronic systems. It uses Simulink as a front-end graphical modeling environment and comes with a range of software tools and libraries for the real-time modeling and simulation of power converters and motor drives. eDRIVEsim is targeted at simulation of the electromechanical system controlled by the RTES and cannot be directly applied to simulation model-based development of RTES software.

2

Several other HITL solutions (for example, see [10,13,14] involve Matlab/Simulink to implement models of RTES-controlled systems (e.g. airframe of an unmanned air vehicle) and surrounding environment. They do not deal with HITL simulation of the RTES under development, or purely-software simulation of the RTES. ProSys-RT real-time simulation software [18], which is used as a platform for HITL testing of Sukhoi Superjet 100 flight control system [7], simulates computer-controlled onboard devices like actuators and sensors. The simulation models imitate external behaviour of the devices, including data exchange over real onboard channels; however, the models do not include real application or system source code for these devices. Purely software simulation of the RTES is also hardly possible, since ProSys-RT does not provide means for simulation of onboard channels. Test and Verification Equipment (TVE) for XMM and INTEGRAL spacecraft projects [5] is targeted at step-by-step integration and verification of the onboard RTES of the spacecraft. It supports HITL simulation involving a mix of hardware devices and simulation models. Verification of RTES can be performed with any combination of real and simulated units; starting from pure software simulations, via integration of a single onboard computer, gradual replacement of software models by hardware units, up to a fully integrated RTES or its subsystem. Early stages of integration involve an emulator of the onboard computer and software models of avionics functional behaviour. Specific feature of TVE toolset is SHAM (Simulation HAndling Module) hardware emulator. Its purpose is to simulate (functionally and timing wise) the hardware of the onboard computer and present an environment in which software for that computer can be tested. Technically, it is possible to use several SHAM’s for simulation of several onboard devices at once, but this it is a more expensive solution for early-stage verification of onboard software than a purely-software simulation. No reports on TVE mention software simulation models of onboard devices that include real source code for these devices and/or provide execution time estimation for the software without involving hardware emulators. dSPACE toolset [9,24] supports rapid control prototyping for embedded controller development. The controller logic is implemented with Matlab/Simulink. Automatically generated code is loaded into standard prototyping hardware and executed, resulting in a hardware/software prototype of the target controller. A technology called bypassing enables joint execution of existing functionality on an existing production controller and new functionality on the prototype hardware. No options are provided by dSPACE for purely-software simulation including simulation of data exchange through onboard channels and reproducing the timings of the onboard software. Application of dSPACE is limited to embedded controllers and other embedded devices that allow development of onboard software based on Matlab/Simulink description with subsequent generation of target code. Onboard software of many aircraft and naval onboard RTES's is written in C and Ada, and use of Matlab/Simulink is prohibited for them. ADI ADvantage [16] is a suite of software tools used to perform simulation-based development and testing of RTES. Development and testing activities available with the ADvantage framework include purely-software simulation and HITL simulation. Featured option of ADvantage is "intelligent integration" which includes construction of a purely-software simulation model of the target RTES and using this model for parallel development activities, eliminating the need for hardware prototypes on early stages of development. On later stages, transition to HITL simulation is performed. Models developed on early stages are loaded into special hardware modules and can take part in HITL simulation, interacting with real hardware devices through real channels. ADvantage supports development of models using different programming languages, including C/C++, Ada and Simulink. However, it is unclear whether onboard application and custom system software written in C can be included as a part of the simulation model. No simulation models of onboard channels (including channels officially supported by ADvantage hardware modules) are mentioned, so it is hardly possible to perform purely-software simulation of the target RTES including simulation of data exchange through onboard channels. Execution time estimation for RTES software tasks is also not supported by ADvantage.

3

Table 1 summarizes the degree of support by the listed HITL simulation environments for steps 1-3 of simulation model-based development and integration of RTES. From the overview presented in this section we conclude that none of the considered environments supports all of these steps. Feature

eDRIVEsim

ProSys-RT

TVE/ INTEGRAL

purely-software simulation of RTES No No No devices involving real source code reproducing realYes time behaviour of No No (hardware software tasks emulation) purely-software simulation of RTES No No Yes as a whole simulation of data exchange through No No No onboard channels transfer of software code from models to No No No real devices HITL simulation, involving a mix of No Yes Yes real RTES devices and models of RTES devices Table 1. Feature summary for HITL simulation environments.

dSPACE

ADvantage

No

No

No

No

No

Yes

No

No

Yes (code generation)

No

Yes

Yes

3. THE DYANA SIMULATION ENVIRONMENT In this section we present the DYANA simulation environment that supports simulation modelbased development of RTES (see steps 1-3 in section 2), with emphasis on RTES software development, RTES integration and architecture evaluation. Next section introduces the HITL simulation capabilities of the environment. Primary goals of the DYANA environment are as follows:  integrated validation of RTES application software and custom system software in context of inter-device communication;  estimation and validation of timing characteristics of RTES software;  validation of data exchange schedules for onboard channels;  exploration and evaluation of technical decisions regarding the RTES architecture. These goals are achieved through construction of RTES device models that include software for real devices, and performing purely-software simulation of the RTES (subsequent transition to HITL simulation is described in the next chapter). The DYANA software runs on Debian GNU/Linux operating system and contains tools intended for performing the following simulation-related activities: 1) development of simulation models of RTES devices and auxiliary simulation models (e.g. model of the external environment), with revision control for models and target devices’ source code; 2) support for execution of the set of models, with support for real-time mode with optional speed-up or slow-down multiplier, and for distributed simulation;

4

parts:

3) automatic control of the simulation process or human-assisted control in dialog mode, with support for manual change of models’ parameters by the user in runtime; 4) dynamic visualization of the simulation state and models’ parameters in graphical and tabular form; 5) recording and analysis of simulation results, including the traced values of models’ parameters and traced events in models. RTES device model involved in simulation model-based development contains the following

1) models for services of the real-time OS, e.g. scheduler, interprocess communication, drivers of channel adapters; 2) wrapper models for software tasks, serving as adapters between DYANA runtime interfaces and C source code of the tasks; 3) C source code of software tasks, included into wrapper models (only tasks written in C are supported). Models from parts 1 and 2 are implemented in a specialized modeling language that is based on a subset of C language extended with functionality and constructs for synchronizing the model execution with real time and for performing intermodel communication. Models for services of the OS are currently implemented for a particular OS, namely OS2000 [15,17]. These models can be reused for modeling of different devices which run OS2000. DYANA modeling technology enables development of similar models for other real-time operating systems. Modeling of uniprocessor target devices is supported. There is no support for SMP's or multicore CPU's yet, however independent uniprocessor boards constituting a single RTES device can be represented by separate models. Since interface to models of the real-time OS services and interface to these services on the real devices are the same, the C-code after simulation model-based validation can be transferred to the target devices without any changes. Backward transfer of code from device to its model is also possible, providing a substitution for the device in case it is moved to in-site testing. DYANA environment provides built-in simulation models for standard onboard channels, presently for MIL STD-1553B [8] and ARINC 429. These models implement detailed simulation of data exchange through these channels. Combination of channel models and models of drivers enable simulation model-based execution and validation of RTES device’s system tasks (defined by real source code) without involving any onboard hardware. By providing the system tasks with specification of data exchange schedules (in target OS-specific format), one can validate these schedules by purelysoftware simulation of the RTES. Build-in channel models support simulation of data exchange errors, e.g. bit inversion, cable disruption for a given terminal device, illegal inter-word interval, illegal length of a word. Data exchange errors can be either triggered by the user via simulation control interface, or coded as probabilistic streams in special models and then automatically injected in runtime. Such simulation-based fault injection provides means for activating the branches of RTES system code that are responsible for error handling, enabling evaluation of dependability features of the RTES. Execution time estimation subsystem of DYANA [21] enables reproducing real-time behavior of software tasks, source code of which is included into the device’s model. The basic technology used for time estimation is compiled simulation [20]. To apply this technology to a device with particular CPU, support for architecture of this CPU must be implemented in the time estimation subsystem of DYANA. Execution time is estimated in runtime, for a particular execution path in the task’s code. The path is defined by task’s input data, which are received in runtime from other tasks from the same device or from different device’s tasks through simulated channels. Since involving compiled simulation slows down the execution of code by an order of magnitude, its use in real-time simulation (including HITL simulation) is restricted to computationally non-intensive tasks and/or simulation of target devices with relatively slow CPU’s (which is often the case for onboard systems). Early evaluation of real-time characteristics of an RTES device via simulation provides estimation for reserve of computational

5

performance on this device. If the reserve is large enough, additional dependability mechanisms (e.g. software reconfiguration) can be implemented on the device. While execution time estimation provides information on task’s timings on given input data for the task, there is often necessary to estimate the worst case execution time (WCET) of a task. WCET estimations are needed for validation of task execution schedules, to guarantee that in the extreme scenario (execution time of each task equals to its WCET) the schedule can be executed in real time. DYANA’s WCET estimation subsystem [19] provides means for WCET estimation for code written in C. It is usually the case that only a subset of the RTES devices (with their software) is developed by a single team in one company. To perform simulation model-based development of software for this subset of devices, in particular to build a simulation model of the RTES, it is necessary to develop simplified simulation models that imitate external behaviour of other RTES devices. Such models only execute given schedules of data exchange and provide basic credibility of the data being sent. DYANA’s modeling language provides facilities for efficient development of such models. Description of these facilities is outside the scope of this paper. Simulation capabilities of the DYANA environment can also be applied on initial stages of RTES development, when the problem of defining the RTES architecture arises. The RTES developer usually has to choose one of several possible RTES architectures. Since most of RTES devices are typically unavailable on initial stages of RTES development, it is impossible to perform full-scale hardware test runs or even HITL simulation to evaluate different RTES architectures. To support architecture evaluation, simplified models of RTES and its devices can be developed and executed via purelysoftware simulation. Devices’ models include stubs of software tasks that are not yet available. Different topologies of onboard data transfer networks can be comparatively evaluated via simulation. For each architectural alternative, following problems of architecture evaluation can be solved with DYANA: 1) estimation of throughput margin on data transfer channels via simulation of data exchange according to real schedules; 2) exploration of RTES resilience to interference on channels by using the channel model’s functionality to simulate exchange failures, including bit inversion, loss of messages, etc. 3) estimation of CPU load on RTES devices by combining execution time estimation for software tasks with available source code with a priori upper estimates of execution time for other tasks; 4) assessing the dependability of the RTES architecture via simulation-based evaluation of fault tolerance facilities of the RTES [25]. Execution of a purely software model of the RTES can be performed in a non real-time mode. If the computational complexity of the RTES model is too high, and it is necessary to run the simulation multiple times or to simulate a long interval of RTES operation, it is reasonable to simplify the model by removing components that are not essential for computation of the RTES characteristics that have to be measured. The technique for automatic scaling of simulation models [22] supports finding and truncating the nonsignificant components of the RTES model, along with reducing the complexity of components responsible for calculation of the essential results of simulation. 4. HARDWARE-IN-THE-LOOP SIMULATION CAPABILITIES OF DYANA On early stages of the simulation model-based RTES development, all RTES devices are represented by simulation models. To perform integration of the RTES, it is necessary to include real hardware devices into simulation. First, when real hardware is available for a device, source code for which was previously executed and tested on a model of the device, the code must be transferred to the hardware. Second, when a device developed by a separate team or organization arrives, it replaces the corresponding simplified model. To support mixed simulation involving real devices and device models, DYANA provides facilities for HITL simulation. During HITL simulation-assisted RTES integration, models are step-by-step replaced by real devices. Models and devices perform data exchange through real channels. On every stage of RTES integration, the integrated set of devices and models is available for analysis and validation.

6

The DYANA environment supports the following HITL simulation-related activities: 1) defining the configuration of HITL simulation, including distribution of models to instrumental computers, and settings for channel monitors; 2) distributed real-time execution of the set of models, including interaction of models with hardware devices through hardware channels; 3) fault injection into hardware channels; 4) visualization and analysis of data recorded by hardware monitors for data exchange channels; 5) interoperation with other similar environments (cooperative simulation).

Figure 1. Structure of the environment’s hardware The environment’s HITL-specific software runs on Debian GNU/Linux operating system with realtime extensions. The hardware part of the environment includes following groups of components (see Figure 1): 1) instrumental computers for simulation (ICS); 2) instrumental computers for channel monitoring (ICM); 3) automated workstations for development of models, preparation and control of experiments; 4) hardware RTES devices; 5) hardware data exchange channels that interconnect RTES devices, ICS’s and ICM’s. Instrumental computers and workstations are x86 PC computers connected to an Ethernet channel. ICS’s perform simulation of unavailable RTES devices through execution of models of the devices (either simplified models, or models including real source code). The deviation of modeling time from physical one is within 10-4 sec. This accuracy is guaranteed by dedicated real-time extensions of the Linux kernel that are part of the runtime subsystem of DYANA. An ICS contains adapter cards that provide access to data exchange channels; supported standards are MIL STD-1553B, ARINC 429, Fibre Channel. Through these adapter cards, the models of RTES devices perform data exchange through the channels in real time, completely or in given part simulating the presence of corresponding hardware RTES devices on the channel. It is important to notice that a model can act as a MIL STD1553B bus controller, to enable integration of a subset of RTES devices that does not include the bus controller. Support for real-time interaction between simulated RTES devices and real ones through hardware channels allows incremental RTES integration with step-by-step replacement of models with hardware devices, up to a complete integrated RTES. In this way testing and validation can be performed with any combination of real and simulated devices. Application and system software of an RTES device, previously tested with models of device’s real-time OS services, can be finally tested and validated on this stage by operating under control of a full-fledged OS. ICM’s perform monitoring of data exchange through channels and record the resulting traces to the hard disk for subsequent analysis. During the simulation, unified time is maintained on all instrumental machines, with deviation between machines limited to 10 -5 sec. A specialized protocol for

7

precise generation of synchronous events is utilized which uses a dedicated network that connects LPT ports of the ICM’s and ICS’s. Periodically, one of the ICM’s (the master of time synchronization) sends a signal through its LPT port and other computers receive the signal and fixate a synchronous event. Registration of all events occurring in models and of exchange through channels is performed in unified time. This enables precise mapping of events in different models and channels to a single timeline. The DYANA environment has an open architecture that enables integration with other similar environments that may be provided by other workgroups. Such integration is reasonable, for instance, when special-purpose computers are required to perform specific HITL simulation-related tasks. Examples of such tasks are real-time generation and registration of video data streams using broadband optical channels, and obtaining control actions from the pilot through actuators in the cockpit simulator. Existing implementation of the DYANA environment utilizes a specialized Ethernet-based data exchange protocol for interaction with external simulation environments. Application of the HLA technology [12] for this purpose is considered future work. Practical applications of DYANA’s HITL simulation capabilities include integration of an RTES containing up to 6 MIL STD-1553B channels, dozens of ARINC 429 channels, and several Fibre Channel lines. 5. HITL SIMULATION-ASSISTED RTES INTEGRATION PROCESS For RTES integration, the DYANA environment has a dedicated subsystem called Scheduler CAD for scheduling of data exchange through MIL STD-1553B channels [3,4]. Scheduler CAD has the following components which are essential for cooperative application of the CAD and the DYANA’s HITL simulation subsystem:  RTES project database that keeps the data: (1) on the RTES structure (set of devices and data exchange channels; topology of the onboard network); (2) on the protocols and formats of data exchange between devices (input and output data formats, structure of messages, schedules of data exchange);  tools for automatic construction of data exchange schedules for execution by RTES devices acting as MIL STD-1553B bus controllers;  tools for generation of schedule definition code for devices that exchange data through MIL STD-1553B channels (including bus controllers and terminal devices). HITL simulation-assisted RTES integration process based on DYANA includes the following steps: 1) filling the RTES project database with data on the RTES structure, on protocols and formats of data exchange between devices; 2) automated generation of interface sections of the RTES device models (including input and output parameters, interfaces of models with channels, interconnections between models); 3) implementation of the functionality logic for models of the devices that are not yet available in hardware, on one of the levels of detail: a) detailed implementation that includes source code of device’s software; b) simplified implementation, imitating external behaviour of the device; 4) automatic construction of schedules of data exchange for MIL STD-1553B channels (by means of Scheduler CAD); 5) automatic generation of code for schedule definition in the following formats: a) unified format for target devices and devices’ models, recognizable by the code of system tasks running either on models or on real devices; b) specialized format for simplified models which do not contain code of system tasks; 6) automatic generation of code for message packing and unpacking in the following formats: a) unified format for target devices and devices’ models; b) specialized format for simplified models; 7) integration of generated code into the models and available real RTES devices;

8

8) preparation of the environment hardware, in particular connecting instrumental computers (ICS’s, ICM’s) and available RTES devices to the data exchange channels; 9) defining the configuration of the environment: distribution of models to ICS’s, settings for channel monitoring and for registration of simulation events; 10) performing the simulation with a given set of hardware RTES devices and device models; 11) analysis of simulation results, including automated verification of conformance of the recorded data exchange sequences to reference exchange schedules from the project database. If there are no hardware devices available on the current stage of RTES development, steps 7-11 involve only simulation models of the devices and constitute a process of “virtual” integration. During this process, real source code for the devices and real exchange schedules are validated. Aside from RTES integration, HITL simulation capabilities of DYANA can be applied to validation of a standalone RTES device. This problem arises, for example, when the supplier of this particular device prepares it for integration. In this case, a simplified model of the device’s environment can be developed that feeds the device’s input interfaces with data through hardware channels, and thus activates the system software responsible for receiving, unpacking and processing of the data. Another model can monitor the data sent through device’s output interfaces and analyze the correctness of device’s responses to test data sets generated and sent by the first model. 6. CONCLUSION In this paper we presented the DYANA simulation environment and described its capabilities to support simulation model-based development and architecture evaluation of real-time embedded systems. A hardware/software environment for hardware-in-the-loop simulation which is based on DYANA was also presented, along with proposed process for HITL simulation-assisted RTES integration process. RTES development and integration testbeds based on DYANA are applied in industry for development of modern onboard real-time embedded systems. Directions for future development of the DYANA environment include:  involving the HLA technology for interaction with other simulation environments in course of cooperative simulation;  integration of simulation tools with monitoring tools from the operating system of RTES devices to enable comprehensive tracking of devices’ operation;  implementation of automatic generation of reports from simulation results. REFERENCES 1. Technical information on the ADvantage framework. Obtained through Internet: http://www.adi.com/products_sim.htm, [accessed 1/12/2008]. 2. Bakhmurov, A.G., Kapitonova, A.P. and Smeliansky, R.L. ‘DYANA: An Environment for Embedded System Design and Analysis’. Paper presented at the 32nd Annual Simulation Symposium. April 11-15, 1999. San Diego, California, USA. 3. Balashov, V.V., Kostenko, V.A., Smeliansky, R.L. and Vavinov, S.V. ‘A Tool System for Automatic Scheduling of Data Exchange in Real-Time Distributed Embedded Systems’. Paper presented at the 7th IEEE International Symposium on Computer Networks (ISCN'06). June 16-18, 2006. Istanbul, Turkey. 4. Balashov, V.V., Kostenko, V.A. and Smeliansky, R.L. ‘A Tool System for Automatic Scheduling of Data Exchange in Real-Time Distributed Avionics Systems’. Paper presented at the 2nd EUCASS European Conference for Aerospace Sciences. July 1-6, 2007. Brussels, Belgium. 5. Brouwer, M.P.A.M., Castelijn, A.A., van Ingen Schenau, H.A., Oving, B.A., Timmermans, L.J. and Zwartbol, T. ‘Developments in Test and Verification Equipment for Spacecraft’. Technical report NLR-TP-2000-658. National Aerospace Laboratory, Netherlands.

9

6. Chan, K.H., Parle, J.A., Johnson, N. and Acha, E. ‘Real-time implementation of a HVDC-VSC model for application in a scaled-down wind energy conversion system’. Paper presented at the 7th International Conference on AC-DC Power Transmission. November 28-30, 2001. London, UK. 7. Cosateq plays key role in development of SSJ100 electronic bird (press release). Obtained through Internet: http://www.airframer.com/news_story.html?release=1898, [accessed 1/12/2008]. 8. U.S. Standard MIL STD-1553B ‘Aircraft internal time division command/response multiplex data bus’, U.S. Department of Defense, Washington D.C., 1978. 9. Technical information on dSPACE tools. Obtained through Internet: http://www.dspace.de/ww/en/gmb/home/products/systems.cfm, [accessed 1/12/2008]. 10. Ferreira, J.A., Quinta, A.F. and Cabral, C.M. ‘Hardware-in-the-loop Simulation Experiments with a Hydraulic Manipulator Model’, Australian Journal of Mechanical Engineering. Vol. 2, No. 2, pp.125132. 11. Harakawa, M., Yamasaki, H., Nagano, T., Abourida, S., Dufour, C. and Bélanger, J. ‘Real-Time Simulation of a Complete PMSM Drive at 10 μs Time Step’. Paper presented at the 2005 International Power Electronics Conference. April 4-8, 2005. Niigata, Japan. 12. IEEE 1516 Standard ‘Modeling and Simulation (M&S) High Level Architecture (HLA)-Framework and Rules’, IEEE, 2000. 13. Jung, D. and Tsiotras, P. ‘Modeling and Hardware-in-the-Loop Simulation for a Small Unmanned Aerial Vehicle’. Paper Presented at the Infotech@Aerospace 2007 Conference. May 7-10, 2007. Rohnert Park, California, USA. 14. Mueller, E. ‘Hardware-in-the-loop Simulation Design for Evaluation of Unmanned Aerial Vehicle Control Systems’. Paper Presented at the 2007 Modeling and Simulation Technologies Conference. August 20-23, 2007. Hilton Head, South Carolina, USA. 15. OS2000 operating system. Obtained through Internet: http://www.niisi.ru/intro1.htm [in Russian], [accessed 1/12/2008]. 16. eDRIVEsim product highlights. Obtained through Internet: http://www.opalrt.com/productsservices/electrical/edrivesim.htm, [accessed 1/12/2008]. 17. Summary information on OS2000 operating system. Obtained through Internet: http://en.wikipedia.org/wiki/OS2000, [accessed 1/12/2008]. 18. Technical information on ProSys-RT. Obtained through Internet: http://www.prosys-rt.de, [accessed 1/12/2008]. 19. Prus, V.V. ‘A Methodology for Worst Case Execution Time Estimation for Processors with Pipelined Architecture’. Paper presented at the 2nd All-Russian Conference on Methods and Tools of Information Processing. October 5-7, 2005. Moscow, Russia, [in Russian]. 20. Reshadi, M., Mishra, P. and Dutt, N. ‘Instruction set compiled simulation: a technique for fast and flexible instruction set simulation’. Paper presented at the 40th conference on Design automation. June 2-6, 2003. Anaheim, California, USA. 21. Savenkov, K.O. and Youshchenko, N.V. ‘A Methodology for Specification of Processor Behavior for Program Execution Time Estimation’. Paper presented at the 1st All-Russian Conference on Methods and Tools of Information Processing. October 1-3, 2003. Moscow, Russia [in Russian]. 22. Savenkov, K.O. and Smeliansky, R.L. ‘Scaling Down Discrete-Event Simulation Models’, Programming and Computer Software, Vol. 32, No. 6, pp.308-316. 23. Smeliansky, R.L. and Bakhmurov, A.G. ‘DYANA: An Environment for Distributed System Design and Analysis’. Paper presented at the 7th International Workshop on Parallel Processing by Cellular Automata and Arrays (PARCELLA '96). September 16-20, 1996. Berlin, Germany. 24. Stolpe, R. and Stroop, J. ‘Prototyping of Automotive Control Systems in a Time-Triggered Environment Using FlexRay’. Paper presented at IEEE 2006 CCA/CACSD/ISIC Conference. October 4-6, 2006. Munich, Germany. 25. Volkanov, D.Yu. ‘Applying Simulation to Estimate Dependability of Distributed Computer Systems’. Paper presented at the 1st All-Russian Conference on Methods and Tools of Information Processing. October 1-2, 2003. Moscow, Russia [in Russian].

10