TRAINING DRIVEN SIMULATOR DEVELOPMENT. Een Pieffers, Harrie Laboyrie. The Maritime Simulation Centre the Netherlands

Transcription

1 TRAINING DRIVEN SIMULATOR DEVELOPMENT Een Pieffers, Harrie Laboyrie Maritime Simulation Centre the Netherlands P.O Box AB Wageningen The Netherlands Tel : (+31) Abstract MSCN has developed Nautical Simulator Systems including Manoeuvring Simulators, Engineioom Simulators and Cargo Handling Simulators They are designed to meet requirements of ship officers, pilots and nautical students to gain or augment their understanding of the behaviour of ships, the effect of external conditions such as wind, waves, current and shallow water, how to deal with tugs, how to control the computerized systems and how to act in case of emergency situations., The Simulator Systems have a modular and flexible set up and can be scaled and adapted to any specific training needs and are hardware independent This paper deals with the development of nautical simulator systems both in terms of technical and training requirements, aspects which are both covered within the MSCN organisation. 1. INTRODUCTION The Maritime Simulation Centre the Netherlands (MSCN bv) has been established as a daughter company of DELFT HYDRAULICS and MARIN Both companies have a world wide reputation in the area of mathematical modelling *"of ships and enviionments, where DELFT HYDRAULICS is specialized in the modelling the behaviour' of ships in restricted waters and MARIN is specialized in the modelling of ships in great detail.. Since 1992 the knowledge in the area of ship simulation has been concentrated in MSCN, MSCN is a company that combines the extensive expertise in the field of mathematical modelling of ships in their (restricted) environment with the most modem computer techniques.. This approach has lead to some major contracts in the past year of which we will mention the contract for the delivery of a full mission simulator to the Nautical college at Ter schelling which consists of a bridge simulator, an engine room simulator and a cargo handling simulator and the contract for the delivery of a complete training centre to the Royal Netherlands Navy., This second contract includes two simulators, and the simulator building, complete with all the necessary infra equipment and a complete inventory The simulators are based on the same philosophy: a distributed computing environment, which gives the best flexibility for now and for the future, and up to standards general available computer techniques, which guarantees that the simulator will be expandable and upgradeble. The simulator's at the premises of MSCN are extensively used for the training of pilots and ship crews. Pilots of ports all over the world are trained in Wageningen. Their remarks on the simulator, both in terms of the important features for' pilot training as in terms of the control of the simulator from the instructor station are incorporated in the design., The simulators are therefore validated by pilots Not only external clients have given their remarks, MSCN training department, involved in amongst others, training development, has set forward their requirements. For more details in

2 this respect reference is made to another MSCN contribution to MARSIM 1993 "On the Effectiveness of training programs" (1993).. Currently MSCN is setting up a quality system in accordance with ISO 9001 (1987), It is expected that this will certified by Lloyds halfway Consequently simulator design and manu-facturing are according to ISO 9001 standards.. 2, REQUIREMENTS The requirements for the simulator 1 systems are set-up in close cooperation with the clients of MSCN, Together with them present and future training needs have been defined. Simulator training requires an easily adaptation of training environment both in terms of playing area and bridge layout. A specific training task defined should be reflected in specific requirements in this respect. Eg, a bridge layout should be adapted to the one which belongs to the ship which is simulated including the ability of latest technology as applied in real-life.. Various ships are to modelled with not only accurate manoeuvring characteristics but also features such as collision capabilities and bank suction forces. During a training all activities and manoeuvres should be logged for' replay during debriefing of a training in order to gain insight in eg. development of trainees performance.. For dedicated training development it is required to have a simulation training environment in which such can be developed, tested and adapted.. Together' with requirements set forward by research and consultancy specifications following requirements can be summarized: modular system, both soft- and hardware; open architecture enabling future ex- pansions both in performance and mathematical calculation capabilities; application of modern computer standards, as much as possible hardware independent; an profitable ratio between cost and overall performance enabling commercial operation of the simulator system. 3. SPECIFICATION 3.1 General The basic concept is equal for all MSCN simulators. Based on specific requirements and budgets available a simulator can be configured.. The following sections will deal with these matters in more detail 3.2 The simulator' modular set-up. Since MSCN also has activities in the field of research and consultancy, the wide variety of training requirements are extended with requirements of scientific research and consultancy., The requirements, imposed by this combination of training and research requests a simulator, which can handle a wide variety of mathematical models and which can easily be changed to other situations, being another ship, another harbour or other circumstances.. The simulator system has been designed for the same goals, The flexibility is achieved by a highly modular design. It is divided into a number of functional components that will be referred to as subsystems Each subsystem in its turn can be considered as a logical unit that fulfils a number of functionally related tasks, Subsystems can be built up from hardware, from software or' from a combination of both.. The modularity is also maintained within the subsystems Each subsystem has been divided into Configuration Items (hardware or software)..

3 Preparation CPU(s) models Outside View system (s) Instructors) JHsauiaa wiwork system(s) Figure 1 The modular 1 set-up Radar sysiem(s) Debriefing Periferal system (s) The modular approach makes the simulator system flexible and expandable. Due to this flexibility changes in the training objectives over' a period of time can be met by a relative small amount of software changes or additions. Due to the expendability the system provides a great potential for future enhancements Hardware Architecture Overview The simulator hardware consists of a number 1 of 'off the shelf work stations., The processors aie connected by a standard Ethernet Local Aiea Network, 3.4 Software Architecture overview The software to be used in the simulator system has been designed using well established principles: Structured Analyses and Object Oriented Design is used to identify all objects within the system. The functions required for each object are identified and combined into loosely coupled cohesive components, Throughout this paper the software is divided into subsystems, Subsystems are deviated into Configuration Items (CI' s); Configuration items are divided into components and components are defined into units, according to the DoD standard (1985), Control couplings between Configuration Items (CI's) are minimized by making a communication manager available to each Configuration Item, This controls access to a shared database containing data for all CI's, along with system state data.. The CI's are stimulated by a regular synchronization pulse from a single master control Data coupling between CI's has been kept to a minimum by ensuring that functions with large common data requirements are grouped together in a single CI. This has the additional benefit of minimising the physical communication overheads between subsystems. All software has been written in Ada and C + +, which is one of the best combinations for simulation systems to date, All user-interfaces will be implemented in the OSF/Motif environment, The inteiaction with the user will be styled according to the OSF/Motif Style Guide, using mouse, menu's, windows, icons etc. 3.5 Simulator Software Decomposition At the highest level, the simulator software may be decomposed in a form which corresponds to the three major phases of an exercise. These are: Preparation Real-Time system Debriefing, Within each of these phases, logically discrete Configuration Items are identified which each fulfil a subset of the training requirements, Figure 2 shows the configuration items within the real-time system, grouped per 1 subsystem,

4 projectors. The projectors are equipped with 8 inch CRT The light output per projector can be 800 or 1200 lumen (10% peak white).. The scan frequency is 64 Khz, which is optimal for the image generating computer., 4=1 Figure 2 Real-time system: Software decomposition L. THE SUB SYSTEMS 4.1 Outside-view display subsystem Introduction An essential component of the simulation system is the outside view subsystem (OSV) which presents a full colour visual scenario of the area around the bridge, A graphics work station generates in realtime the actual covering of a sector of 35 degrees of the total viewing angle of maximum 360 degrees The visual scene The visual scene can include, beside terrain, waterways, buildings etc., a number of special effects like wave height dependent sea texture, instructor controlled visibility, all kinds of navigational light with appropriate colouring, sectoring, occulting and isophase characteristics, cultural lights The global software structure. The global software structure of the Outside View sub-system is relatively simple and can be defined in terms of related objects as shown in the Figure 4.. Ccnnunfcotion [ L \ Predictor ] / \ / Hun-time \ ^. ;A TopoData / / Display \^ \ Monag«r / J Erivlranntfnt j 1 Graphics \Sub-syste Figure 4 structure. Global rendering softwt 4.3 Bridge subsystems. Figure 3 Vertical viewing angle The vertical viewing angle can be determined by the size of the windows of the bridge. A video projector' will be connected to the image generating system for 1 each display sector on top of the bridge The total system consists of a number 1 of image generating computers and an equal number' of projectors The projection system The projection system consists of a number of Introduction The consoles of the bridge can be look alikes of the consoles of the simulated ship.. The same holds for the instruments Hardware control All instruments are controlled by a front-end processor, The connection between the front-end and the consoles is realised by standard connectors, This means that consoles can be changed and connected to any connector on the patch panel. The standard solution will also allow changing of instruments within a console,

5 4.3.3 MANCON MANCON is a software inter face module designed to drive the bridge-consoles.. MANCON knows, by means of a configuration file, the physical connection of the instruments to the front-end processor I/O board position If an instrument or a complete console is changed, this configuration file has to be adapted. own-ship components and for' the environmental sounds are stored in a central database and are loaded in the front-end processor during initialization by the system loader'. The principal MANCON-functions are reading both analogue and digital input consoleinstruments and writing both analogue and digital output console-instruments AMPL/lilHEH SYNTHESIZER AUFL/MIXER Output-instruments controlled by MANCON are in the area of (amongst others): environmental display (e..g. wind-direction), engine display, navigational display, rudder display.. Figure 5 The Sound subsystem AA NAVLAB Subsystem 4.6 Mathematical models The NAVLAB system consists of a dedicated instrument console with navigation aids. This instrument console is connected into the realtime LAN by means of a front-end processor 1. During the simulation the readings of the various positioning systems are calculated. A reading is biased by an error which consists of a systematical error (specified beforehand) and a random noise, of which the variance can be adjusted during the simulation. The calculation modules respond to the commands issued by the trainee through his operating panel, and to the input from the instructor. The position indicated by the instrument corresponds with the movement of the simulated ship, controlled from the bridge. 4.5 Sound subsystem. The sound subsystem consists of a front-end computer', capable to handle MIDI standard synthesizer cards (see Figure 5).. Each specific function is modelled on a card and will be processed separately before the signals are mixed and fed into an amplifier 1. The sound spectra for 1 each of the specified OWNSHIP OWNSHIPS are defined as the most detailed ship models in the simulator. OWNSHIP software is used for all ships that are manually controlled (i e by explicit rudder', propeller' etc., commands), regardless of by whom.. This section describes the possible usages of ownships, and then looks into the design of an ownship in order to describe exactly how detailed a model can be.. At the highest level, this design can be decomposed into three levels; AUTCON, ENGINEROOM and MATMOD. Each of these is described below An OWNSHIP has to be controlled from the bridge.. MATMOD shall deliver positions, orientation angles, velocities and angular' velocities of a floating ownship object at each time step as a function of the state of controls such as rudders and propellers, environmental influences such as wind, current, depth and waves (obtained from ENVIRONMENT), and external influences, such as, lines and effects due to other ships.. Wind effects will take into account the fore and aft structure of own ship as well as wind aspect when calculating the effects on current

6 manoeuvre.. The functioning of MATMOD can be described by three equations The velocity components are calculated at each moment by means of an integration procedure of the acceleration components, which have been derived from Newton's 2nd law, By a time integration of the velocity components, the position and orientation angle of the floating object are determined at each point of time.. The position and orientation angles are corrected for 1 first order' motions due to waves, For a determination of the accelerations use is made of Newton's 2nd law: a = M-l F in which: a = a(t) = momentary acceleration.. Besides the transformations, needed to assure that all variables are represented in the same coordinate system, MATMOD reflects the structure of the mathematical manoeuvring model describing the dynamics of the floating object, Because the modelling of ownships is performed at such a low-level, the higher level characteristics of ship's behaviour are more reliable for a larger range of conditions.. This would not be the case if the required high level characteristics under a discrete number of conditions (eg required turning circle at a given speed) were stored and then used directly to predict ship behaviour. This principle is essential in giving a real-world 'feel' to a simulated ship.. The structure of MATMOD allows for mathematical models which include many components, furthermore some of the components can be used repeatedly (eg propeller), and all can be completely replaced with a new mathematical description for the quantity that they are modelling, (eg a fixed propeller can be replaced with a variable pitch propeller) These components are: F = F(t) resulting momentary excitation force that may effect the floating object one way or' another., M = Mass matrix: a matrix is used rather 1 than deadweight to reflect that different amounts of inertia to movement are obtained depending on ship orientation t = time. The force and mass in this relation depends on many factors, such as the environmental conditions, the actions of the control devices, the position and velocities of the floating object, state of the ships hull. a) b) c) d) e) i) g) h) i) j) k) 1) m) n) propulsion forces; rudder' forces; anchor forces; hydrodynamic reaction forces; current effects; wind effects; wave effects causing (first order motions, wave drift forces, translational wave forces); shallow water' effects; restricted water effects; cushion effects line effects; collision forces; multi body interactions; user 1 defined forces.. MATMOD determines or 1 collects all the forces acting on the floating object, transforms all forces, velocities and mass matrix to an earth fixed system of axes and solves the equations of motion These components are completely flexible, they can be tailored to suit the ship model by changing configuration values, and they can be independently re-written It is not compulsory to use all modules when modelling each ship, many ship models will be produced that contain

7 some dummy, null modules Thus any component, such as rudder, propeller 1 or an environmental effect can be changed in exercise preparation, removed or added, without affecting other 1 components or the functioning of the complete mathematical model. This is most useful for allowing simulator owners to re-use ship models of their own that may already exist, simply by adding a standard interface to them, ENVIRONMENT The real-world characteristics will be modelled to the specified extent. Data resolutions to be provided will be comparable to those obtained on hydrographic or standard stream atlas charts.. Each exercise area shall be defined in terms of all the above characteristics ENVIRONMENT allows the modeller to define these characteristics with a resolution of his choice. Because a grid system is used, perceived depth changes will be continuous, not discrete.. The seabed mapping will be consistent with the hydrographic charts obtainable for each harbour and approach, to an accuracy of lm out to the 50m depth contour line. The number of depth points provided for each area will vary according to charts available, an estimate for 1 the number of depth points provided in say, 1000, but this is no way represents a maximum figure Targets Target is the subsystem which simulates ships and aircraft in level flight moving semiautonomously within the simulator environment, via way-points, along preprogrammed tracks. After 1 initialisation the behaviour of the targets can only be controlled and manipulated by the Instructor 1., During real-time simulations target-objects are made available to simulate 'real-world' shipping traffic. These ships have simplified hydrodynamic models, and move realistically with 3 degrees of freedom (X and Y position and orientation) about the exercise area.. Their positions and orientations relative to the main bridge ownship will be reflected in their' outside view appearance. TARGET ship dimensions will, to the limits of pixel resolution, be proportionate to the distance from the main bridge ownship, thus allowing visual range finding techniques to be employed, 4.7 Instructor subsystem Introduction From the instructor subsystem an instructor is capable of controlling the progress of a simulation run. An instructor can also make adjustments and alterations in simulator run-time information to influence and manipulate the standard behaviour of simulated ships, weather conditions, current, etc. and introduce unexpected situations such as e.g. black-outs, engine failures, jammed propellers, stuck rudders, etc., From the instructor subsystem the instructor 1 can have full control of all, to the simulation project assigned, tugs and make alterations in the preprogrammed tracks and behaviour of target ships that autonomously move within the project environment. To fulfil these complicated tasks an instructor needs a comprehensive overview of all necessary simulator run-time information and the ability to "zoom in" on information details. Great effort has gone into the design of an ergonomic method of presentation of this vast amount of complex information, The basic solution is a series of graphical displays, which are provided in a windows environment so the instructor can taylor the style of presentation to his own requirements The software The instructor 1 software is the first software to appear active when the simulator' is started.. Once active, after displaying some introduction screens, the instructor 1 software will display the runselector screen. Once a run has been chosen the simulator can be

8 controlled by the simulation manager. Via the area manager a "birds eye view" of the playing area will be presented from which the traffic in the exercise can be controlled. A tugseiver and a datamanager complete the instructor software., The runselector allows the user to select an exercise by specifying a projectname and condition from those available. The runselector 1 will then generate a run-number as identification for' the current run, which the user' is capable of overwriting if so required Once a run is selected the runselector 1 will present some of the initial environment data, and will allow a last minute change.. Once the user is satisfied with the project, condition, runnumber, and initial environment data, the system control process is invoked and these identifications passed to it Providing that system control initialises the simulator successfully then the instructor 1 is capable of controlling the cunent simulator state by means of the simulation manager.. Via the simulation manager the user can control the state of the simulator. Furthermore it is possible to introduce a marker' in the datalog file, to toggle the rules in the scenario file, and to introduce failures in the system.. The simulator will come up in the HALT state, The instructor can control the state of the simulator'.. The area manager provides a "birds eye view" of the playing area. This will be a graphical representation of a plan view of the simulation volume. This plan view contains a graphical representation of all major 1 simulation entities, such as ships, buoys, coastlines reference point's etc.. However 1 to prevent the instructor from suffering an "information overload", it is possible for 1 him to toggle on/off some of the information The area manager is not a purely passive display.. Target ships and special dynamic objects can be controlled from the area manager Radar subsystem MSCN has developed two radar systems which can be integrated in the simulator systems; MSCN Radar, a completely simulated radar and RADSIM 100, a radar system in which the radar' itself can be any commercially available radar., Radars include all normal radar' controls and have the possibility of simulating typical shortcomings Preparation subsystem The preparation subsystem facilitates the manipulation of the central database. The central database is project independent and holds all ships, all environments, all outside-views., Another impor tant task of the preparatron subsystem is the generation of all necessary runtime data-structures (e.g. the outside view, birds eye view, display lay-out of instructor station etc) Run time data structures are project dependent, and will be picked up by the simulator' during initialisation of the real-time simulator 1 system. In the preparatron phase of the simulator the use has several tools to simplify the task of preparing a simulator-run, These tools are referred to as the preparation program, The preparation subsystem of the simulator allows the user to prepare, configure and edit the input required for simulations,, The preparation subsystem works on a centraldatabase which contains all data necessary to perform a simulation (see Figure 6), The preparation subsystem consist of several separate editors for the input of several data in the central database. Furthermore it is possible to validate the data which is available when composing conditions and projects. In Figure 7 an example is given of the possible activities an user can select.

9 Preparation System 1 l/f j j Piped : Central Database _J l/f 1 CdRIds \ I l/f j P'P ttds j Run Time Data Set tionality is available such that mistakes can be corrected by re simulating. Debriefing as can be an off line activity. Off line indicates that no connection to real time simulator subsystems is required for the debriefing task.. All information logging function (DATALOG) which performs the task of constantly monitoring the real time environment communications during the run(s) of training exercises. Figure 6 subsystem i=j Hie Edit < Relationships Project Condition Dynamic Topology Scsnary D> PREPSIM Hydrolest Rtds Toola Preferences Preparation D Figure 7 Preparation subsystem screen (example) The File options allows the user to exit the session. The editors can create, modify and save projects, condition and objects within them 4.10 Debriefing subsystem The debriefing facilities of a work station, monitor 1 and printer 1 provide the means of debriefing personnel involved in training and/or research projects about actual simulation runs It also provides an opportunity for the instructor to make a subjective assessment of the trainees' performance. Facilities for debriefing are offered both during and after realtime simulation, The realtime facilities offered are the 'video recorder' style controls of simulator time, which provides the means to simulate, halt, rewind, and review trainees' actions/mistakes. Additional func Help The analysis shall be performed on the log files that are made available to the debriefing subsystem after a training run has been completed. Examples of previously played exercises can be used as an aid to briefing new students, The debriefing facility shall be capable of making hard copies from the on screen data overviews selected by the instructor on printers and/or' plotters.. All data which passes between software modules shall be recorded and can be used in debriefing for assessment purposes This includes model generated data and operator' actions which affect the mode. However, actions which are entirely local to a device (eg. Radar display controls and some NAVAID controls) are not recorded. The simplest and most intuitive way to present information to instructor personnel during debriefing is to reuse the displays that they are familiar with from their realtime simulation control. The main Instructor's main control tool, the area manager is therefore provided as part of the debriefing facility. Its functionality will be restricted to all the display facilities that it provided during simulation, such as : all ship tracks with histories, land masses, buoys, zoom operations, pan etc. The many control functions that were available, are not applicable during debriefing as only downloaded data can be used. The traversal of the log data is under direct Instructor control, by the provision of Halt, Play (at three speeds, normal, fast and very fast), and reposition operations.. Wherever possible, input of parameters to drive these options will be allowed by natural, user friendly means. For example, a reposition to a past point in an

10 ownship's history can be achieved by literally dragging the ship symbol to its position at the point of time that was of interest.. Alternatively, positioning to previously defined (during realtime) 'point of interest' marks, can be performed directly. Where re-simulation of an exercise did occur, both incorrect and corrected versions of a trainees actions can be viewed. This facility is available for' all trainee controlled tracks. Area manager is a valuable tool for providing an overview of ships' track history at a high level. However, it is recognised that once points of interest in the history have been identified, a more detailed inspection of trainee actions is required., To a certain extent, the audio recordings help this, but a more useful guide would be the actual low-level values that describe the state of a ships components at any moment in time. Figure 8 Layout User Interface 5. REFERENCES tknr rsjfia i-ms V-fllH M dre rfpltcs j-lrtj V-tffB stow rsibff dot d(n TTjJra >-lbl T-WK mot IvB^I lilwl 53Z1 Examples of such quantities would be values that are under 1 control of the trainee, such as requested and actual rudder 1 angles, engine rpm etc. and environmental values such as prevailing current, wind and wave force directions etc.. The Instructor can specify a selection of five such values to be displayed on the screen.. The presentation of these values will be in graphical format, plotted against playback time, with instantaneous values being displayed explicitly. As the values that can be selected for 1 display can be taken directly from anywhere in the communications data area, the debriefing facility provides a useful mechanism for viewing lowlevel entities during maintenance exercises.. Figure 9 shows a suggested screen layout. Any debriefing screen can be dumped straight to a printer to provide a hardcopy facility. A more detailed breakdown of trainee bridge operations is also proposed This will be a time based list of all operations that were performed on the bridge under 1 the control of MANCON.. Again the production of this list will be synchronised with the playback speed.. International Organisation for Standardization (1987) International Standard ISO Quality systems - Model for quality assurance in design/development, production, installation and servicing. Ter Hedde, R,; Perdok, I (1993).. On the effectiveness of training programs. Training design and quality assurance. Military of Defence, (1985), DOD STD 2167 A, Documentation of Defence, Defence System Software Development.