1 / 49

Remote Testing

Remote Testing. Agenda. Hardware-in-the-loop (HWIL) testing overview SimREMOTE setup and interfaces Remote scenario control and monitoring Remote vehicle motion Timing and latencies Integration considerations. Agenda. Hardware-in-the-loop (HWIL) testing overview

mabli
Download Presentation

Remote Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Remote Testing

  2. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  3. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  4. Hardware-in-the-loop (HWIL) Testing Overview • System integrators and developers require testing for evaluation of their systems using the system hardware and software as described below • Depending upon the test requirements, the system test environment may be open loop, such as sending vehicle motion from a file, or closed loop, such as sending new vehicle motion from the output of a flight control system or pilot interface, as described below Signal Generator Open UUT Closed Remote System SimGEN Proprietary & Confidential—Page 4

  5. Hardware-in-the-loop (HWIL) Testing Overview (cont.) • HWIL testing presents many challenges in order to support the diversified needs, interfaces and motion data rates accurately and effectively • Some remote HWIL testing applications only require remotely controlling the simulator for test automation or changing test scenarios and parameters • If sending remote motion data, motion data fidelity, timing and latencies can produce undesired results during HWIL testing if not handled correctly • Thus, synchronization between the remote system and the simulator test environment is paramount for effectively modeling the desired motion in real-time Proprietary & Confidential—Page 5

  6. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  7. Spirent Remote Testing Support • In order to address the need for a hardware and software interface to support remote testing, Spirent developed SimREMOTE which is a package of remote control facilities that greatly enhances the flexibility of SimGEN • Depending upon the scale of your testing, these facilities can meet every need from simple remote control through to full HWIL integration • Using SimREMOTE, customers have the ability to remotely control or monitor SimGEN as well as inject remote motion data to simulate any desired trajectory • Addressing the HWIL challenges, data timing and latencies are mitigated by a Spirent specific test method of ensuring continuous real-time data generation to the unit under test (UUT) even when variably receiving data • Standard with all of Spirent’s products, synchronization is supported through various methods and the resultant performance is dependent upon the fidelity of the remote motion data Proprietary & Confidential—Page 7

  8. SimREMOTE Overview • SimREMOTE is SimGEN’s remote control and remote trajectory (motion) data capability • This is not a separate software package, but standard within SimGEN • It may require additional interface hardware • Defines the custom syntax for control and motion messages • Supports Control of SimGEN, for example: • Start/stop scenarios, command parameter changes (power, sats on/off, multipath on/off etc.) • In addition, it provides the interface for remote trajectory delivery which supports: • Real-time reception of motion commands from an external system or file (as opposed to using SimGEN’s vehicle models) Proprietary & Confidential—Page 8

  9. SimREMOTE Overview (cont.) SimREMOTE supports several physical interfaces for easy integration into various test systems The standard SimREMOTE interfaces supported with SimGEN are the following: TCP/UDP IP – Ethernet RS-232 Local disk command file An OPTIONAL SimREMOTE package includes a network enabled PC with an Amplicon PCI215 timer card for synchronization and optional interface cards, such as IEEE-488 and SCRAMNet Cables and example programs are also supplied for assistance Proprietary & Confidential—Page 9

  10. SimREMOTE Overview (cont.) The principals of operation using the SimREMOTE capability with SimGEN is described below System control and motion generation Scenario Commands & Motion Trajectory(s) GPIB Command responses & Truth vehicle or satellite data Send data to other systems Receiver Position & Status RF Proprietary & Confidential—Page 10

  11. SimREMOTE Overview (cont.) • The interface used for the SimREMOTE commands must be specified in SimGEN under the Remote Command Settings as shown below Proprietary & Confidential—Page 11

  12. Remote input over IEEE-488 GPIB for receiving commands and motion via the IEEE test equipment interface (requires additional IEEE card) Enable remote inputs, else SimGEN won’t use the remote data Remote input from a file for scripting commands or motion data from a specified location Remote input data over RS232 for basic commands or motion Use the SCRAMnet interface for remote commands and motion (requires SCRAMNet card) Remote input over TCP/UDP Sockets for receiving remote command or motion data across a network or other PC Log received messages from the remote interface for analysis and replay SimREMOTE Overview (cont.) • If supported by the hardware, the interfaces can be enabled as described below Proprietary & Confidential—Page 12

  13. SimREMOTE Overview (cont.) • If using remote motion data for one or more vehicles, the vehicle needs to be designated as a Remote vehicle in the Scenario Tree shown to the right • Specifying a Remote vehicle, this will bypass the defined vehicle limits in the personality file • Thus, SimGEN applies the received remote motion directly to the Remote vehicles regardless of the dynamics • This is useful for bypassing SimGEN’s limits for dynamics beyond SimGEN’s models • Additional details are shown in the SimREMOTE User Manual Proprietary & Confidential—Page 13

  14. SimREMOTE Overview (cont.) • Although bypassing the vehicle Personality file, the remote motion data dynamics is still limited by the signal generator dynamic range defined in the Hardware specification • The Remote motion settings are NOT defined for the scenario, but for SimGEN, thus a different scenario can be selected but the Remote Settings will remain the same • Common operation errors when using Remote vehicles and motion are: • A remote vehicle specified, but not the remote motion interface (IEEE, TCP, FILE) • Not specifying the correct remote motion file • Not selecting a Remote vehicle Proprietary & Confidential—Page 14

  15. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  16. Remote Control and Monitoring • Some test requirements require remotely controlling or monitoring scenarios to perform or view various operations and conditions • SimGEN’s SimREMOTE capability provides a generic method for allowing real-time, external, interactive control over some parameters and simulator operations • These commands can be sent from the remote system to SimGEN synchronously or asynchronously at the simulation iteration rate up to 250Hz • Some examples of these commands for control and monitoring are: • Select, Start and Stop Scenarios • Control Signal Powers for each satellite • Offset signal code and carrier phase, etc • Unique capability to Spirent • View current vehicle position or scenario time Proprietary & Confidential—Page 16

  17. Remote Control and Monitoring (cont.) Remote control and monitoring commands There are >140 remote commands currently implemented, with more continuously added to support changing requirements All commands are ASCII based, making them easy to view and write Some examples for controlling a scenario are the following : “Select scenario” by sending the ASCII command  SC,<scenario dir> “ARM” the simulator and scenario by sending the ASCII command  AR “RUN” the scenario by sending the ASCII command RU It is important that after the remote system “writes” the command to SimGEN, that it then performs a “read”. This sequence should always be maintained and is described below. Write Read Proprietary & Confidential—Page 17

  18. Remote Control and Monitoring (cont.) After writing the command, the read is performed and provides an XML response as described below <msg> <status> <status_value> <\status> [<data> <data_value> <\data>] [<error> <error_value> <\error>] [<fatal> <fatal_value> <\fatal>] <\msg> Status (<status> <status_value> <\status>) is always present and represents SimGEN’s current status i.e. Ready, Arming, Armed, Running etc… Data (<data> <data_value> <\data>) is only present if the command sent to SimGEN was to request data The remote system must read all of the responses before writing another command. This may take more then one read to complete. Read 1 Read 2 Read 3 Proprietary & Confidential—Page 18

  19. Remote Control and Monitoring (cont.) SimREMOTE supports several timed commands to perform control or monitoring commands at desired times Some commands may be be performed immediately when SimGEN receives the command by using the following symbol in front of the command to immediate stop the scenario or change the signal power for example “-” For example: -,veh_x_pos,v1 Or the commands may possess a specified time of applicability for when SimGEN will action the desired command This may have the format of [D] HH:MM:SS[.ms] This is a defined timestamp into the run with optional days and milliseconds for example: 00:01:00.00,veh_x_pos,v1 Or it can have the format of SSSS.SS This is a defined time in seconds into the run for example: 60.00,veh_x_pos,v1 Proprietary & Confidential—Page 19

  20. Monitoring SimGEN In addition to using SimGEN’s datastreaming capability for monitoring, the SimREMOTE commands can be used to montior SimGEN via the Transmission Control Protocol (TCP) and ASCII commands For example the user may want to know the current vehicle ECEF X position as described below Remote system injects  -,veh_x_pos,v1 The XML response from SimGEN would be the following: <msg> <status> <5> <\status> <data> <8.00123> <\data> <\msg> Proprietary & Confidential—Page 20

  21. Monitoring SimGEN (cont.) Using the SimREMOTE commands, the remote system can monitor vehicle, antenna, signal and transmitter data analogous to what is available via SimGEN’s quicklook Other examples of these TCP monitoring commands are: VEH_<group>  VEH_X_POS, VEH_LAT, VEH_BANK, … ANT_<group>  ANT_X_POS, ANT_DOP, … SIG_<group>  SIG_X_POS, SIG_AZIM, SIG_PRANGE, … TX_<group>  TX_SVID, TX_POS, … The Vehicle group is shown to the right Proprietary & Confidential—Page 21

  22. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  23. Remote Vehicle Motion • Some tests require motion data to be generated in real-time from a flight simulator, flight computer or another PC • For instance a pilot may be in the loop flying an aircraft simulator that is continuously updating position and attitude information to the simulator for driving the navigation system • In order to implement this test environment, the motion data from the flight simulator or other system has to be supported by SimGEN in order to be used for generating the GPS, Galileo, GLONASS RF, inertial data, etc. • So in addition to control and monitoring, SimREMOTE supports delivery of remote motion data as well for use in the simulation Proprietary & Confidential—Page 23

  24. Remote Vehicle Motion (cont.) • SimREMOTE provides a generic method for delivering vehicle trajectories that supports real time, open and closed-loop RF simulation • Just like the control and monitoring implementations, the remote motion data can be run from a file or received various communication interfaces • The data can be transmitted to SimGEN at rates up to 500Hz for Ultra High Dynamic applications • This allows SimGEN to read and use the latest received sample from the Remote System at up to the Simulation Iteration Rate (from 10 to 250Hz) • The remote motion data supports 6 Degrees of Freedom (6DOF) vehicle data for complete vehicle dynamic testing • 3-axis Linear data with derivatives of Position (m) up to Jerk (m/s³) • i.e. Position, velocity, acceleration and jerk • 3-axis Rotational data with derivatives of Angular Rate (rad/s) up to Angular Jerk (rad/s³) • i.e. Heading, elevation, bank and angular velocity, acceleration and jerk Proprietary & Confidential—Page 24

  25. Remote Motion Formats Since the remote system will typically transmit the remote motion data early, it is essential that SimGEN applies the specified motion at the correct times into the simulation Similar to several control and monitoring commands, the motion commands are also timed commands that SimGEN can action immediately or a desired time In addition to time, the remote system can provide motion data to SimGEN in two different reference frames to support various motion models The desired model is designated by the specify remote command described below MOT command (Earth Centered Earth Fixed) reference frame with respect to WGS84) MOTB (Lat, long, height and linear motion with respect to local geographic frame North, East, Down (NED) Both formats support a large number of input parameters but the minimum requirement is for position and velocity to be provided on all three axes. It is recommended however to provide acceleration and jerk because of the improvement in fidelity and SimGEN’s ability to handle data latencies Proprietary & Confidential—Page 25

  26. Remote Motion Formats (cont.) • The remote MOT and MOTB motion data formats support the 6-DOF data necessary for accurate representation of vehicle and antenna dynamics. The remote command message is described below. • <timestamp>,mot,<vehicle>, <x>,<y>,<z>, <vx>,<vy>,<vz>, <ax>,<ay>,<az>, <jx>,<jy>,<jz>, <h>,<e>,<b>, <wx>,<wy>,<wx>, <ώx>,<ώy>,<ώz>, <ωx>,<ωy>,<ωz> • Time of Application (Toa), vehicle (1, 2, 3, etc.), ECEF Pos (x,y,z), Vel (x,y,z), Accel (x,y,z), Jerk (x,y,z) • Vehicle Attitude (Heading, Elevation, Bank), Body Angular Vel (x,y,z), Accel (x,y,z)and Jerk (x,y,z) • <timestamp>,motb,<vehicle>, <lat>,<long>,<height>, <vel_north>,<vel_east>,<vel_down>, <acc_north>, <acc_east>, <acc_down>, <jerk_north>, <jerk_east>, <jerk_down>, <h>, <e>, <b>, <wx>,<wy>,<wz>, <ώx>,<ώy>,<ώz>, <ωx>,<ωy>,<ωz> • Time of Application (Toa), vehicle (1, 2, 3, etc.), WGS-84 (Lat, Long,Height), Vel (n,e,d), Accel (n,e,d), Jerk (n,e,d) • Vehicle Attitude (Heading, Elevation, Bank), Body Angular Vel (x,y,z), Accel (x,y,z)and Jerk (x,y,z) • Note: Parameters may be omitted from the end of the list, in which case they will be taken as a zero Proprietary & Confidential—Page 26

  27. Remote Motion Formats (cont.) • Just like other remote commands, the motion data must NOT have any syntax errors when sent to SimGEN else SimGEN will ignore the motion data • An example of a remote MOT command ASCII motion data sequence is shown below MOT command Time of Applicability Vehicle 1 and Motion 1 (always set to 1) Vehicle Motion for first 100ms 0 00:00:00.00,mot,v1_m1,6378137,0,0.000000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 RU 0 00:00:00.10,mot,v1_m1,6378137,0,0.010000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.20,mot,v1_m1,6378137,0,0.020000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.30,mot,v1_m1,6378137,0,0.030000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.40,mot,v1_m1,6378137,0,0.040000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.50,mot,v1_m1,6378137,0,0.050000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.60,mot,v1_m1,6378137,0,0.060000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.70,mot,v1_m1,6378137,0,0.070000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.80,mot,v1_m1,6378137,0,0.080000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:00.90,mot,v1_m1,6378137,0,0.090000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:01.00,mot,v1_m1,6378137,0,0.100000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:01.10,mot,v1_m1,6378137,0,0.110000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:01.20,mot,v1_m1,6378137,0,0.120000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0 00:00:01.30,mot,v1_m1,6378137,0,0.130000,0,0,0.1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 -, EN,1,1 Run Scenario End, Immediately, Rewind, Save Logs Motion for each 100ms time period for the vehicle Proprietary & Confidential—Page 27

  28. Remote Motion Data Considerations • SimGEN’s models generate good, consistent motion data for producing a representative trajectory during the simulation which isn’t always the case with user generated data • In order to ensure the quality of the motion data represented by the RF from the signal generator, some considerations must be made when using user generated motion data • One of the primary causes for unexpected receiver performance (e.g. loss of satellites or problems tracking) is the consistency of motion data • The higher order derivatives must be consistent with the position and velocity data • This can be checked using the check_mot.exe utility in the SimGEN root folder • Inconsistent data can also cause GBLK or NBLK scaling errors observed in the Messages Window which can degrade performance • Using logged data from a flight or car for example may introduce some unwanted effects of noise and “jumping” in position because of poor DOPs or multipath Proprietary & Confidential—Page 28

  29. Injecting Remote Motion Data TCP vs UDP The remote MOT and MOTB motion data can be supplied to SimGEN in either ASCII (TCP/IP) or binary (UDP) formats if using the Ethernet interface The Pros and Cons of using either TCP or UDP is presented below The other interfaces (except SCRAMNet) must use the ASCII format Proprietary & Confidential—Page 29

  30. UDP Remote Motion Data If using UDP remote motion data, the definition of the UDP binary message is shown below The format is little endian packed on an 8 byte boundary Reference SimREMOTE User Manual for additional details Header specifies the motion data type (MOT or MOTB) Specify the Time_action to tell SimGEN when to initiate motion command Vehicle information for providing motion data for more then one vehicle Generated motion data (pos, vel, …, heading, elev, bank, body rates, …. This data is only included in the binary logging file. Positive number – data arriving early (before SimGEN epoch). Negative number – data arriving late (after SimGEN epoch) Proprietary & Confidential—Page 30

  31. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  32. Timing Timing is essential for effectively synchronizing SimGEN with the remote system This aids in remote motion delivery and in initialization and start-up of the simulation when using other equipment in the loop such as bus controllers, flight computers, etc. To ensure proper timing, the remote system and the signal generator(s) must use the same timing references Spirent signal generators use the rising edge of a 1PPS signal as a time reference For flexibility with various test environments, the signal generators have the capability to generate a reference clock signal to be used by other systems for synchronization or they can lock to an external reference signal generated by some other test equipment Proprietary & Confidential—Page 32

  33. Timing (cont.) Depending upon the test requirements, it is important that SimGEN is started at the right time For instance, the remote system may need to start other equipment before starting SimGEN, or start SimGEN then wait until the remote system or other equipment is ready To support these varying start-up demands, SimGEN can be started using several remote control commands described below: RU Arms SimGEN and commences the RU (Run command). Note that the command will not return a reply until the scenario has started RU_NOWAIT Same as the RU command but the command will return a reply immediately. This is so a client can carry on with initialization and listen for a state change via a separate method i.e. datastreaming from SimGEN Or AR and then RU Sending the AR command will cause SimGEN to arm the scenario – (this part takes the longest). The RU command will then cause SimGEN to run on the next 1PPS depending upon the trigger mode… Proprietary & Confidential—Page 33

  34. Timing (cont.) Once SimGEN is commanded into the desired start-up run sequence, the start of the run can be initiated through three types of trigger modes (Disabled, Immediate, Delayed) An overview of the remote test environment hardware configuration is shown below, which permits synchronization with external equipment using: The 1PPS output from the signal generator or… The trigger input (TRIG IN) on the signal generator Proprietary & Confidential—Page 34

  35. Timing (cont.) For typical scenarios, the SimGEN trigger mode is Disabled This is the default SimGEN trigger mode or can be specified with a TR,0 remote command This triggers SimGEN to start on the next 1PPS event – first 1PPS event after ARMED state is achieved (if RU or RU_NOWAIT sent) shown below Proprietary & Confidential—Page 35

  36. Timing (cont.) The trigger mode can also be configured as Immediate This can be specified with a TR,1 remote command This is a hardware trigger start where SimGEN starts immediately following the reception of the trigger on the TRIG IN input shown below Note SimGEN must be in “trigger wait” state so a RU command still needs to have been sent PRIOR to the trigger Proprietary & Confidential—Page 36

  37. Timing (cont.) The trigger mode can also be configured as Delayed This can be specified with a TR,2 remote command This is a hardware trigger start where SimGEN starts on the next 1PPS following the reception of the trigger on the TRIG IN input as shown below Note SimGEN must be in “trigger wait” state so a RU command still needs to have been sent PRIOR to the trigger Proprietary & Confidential—Page 37

  38. Timing (cont.) Some test environments require arming of additional test equipment or arming of SimGEN first before arming other equipment SimGEN supports these unique arming test needs with the following SimREMOTE commands REGISTER_EXTERNAL_ARM Sent by remote system client to stop SimGEN from entering the ARMED state until all external arming sources have reported that they have ARMED. Returns a unique ID to be used in linked commands EXTERNAL_ARMED Sent by remote system client with unique ID to inform SimGEN that they are ready and have ARMED DEREGISTER_EXTERNAL_ARM Sent by remote system client to inform SimGEN that the client no longer wishes to be part of the ARMING sequence Proprietary & Confidential—Page 38

  39. Latencies • Open and closed loop systems have latencies from transmission delays, processing delays and delivery for converting the digital data to analog RF • Transmission delays can vary depending upon the medium used, bus traffic and transmission rates • SimGEN’s processing delay is <1msec to receive and process the remote data • The delivery delay varies upon the Simulation Iteration Rate used, but can be as small as 4msec (250Hz Iteration Rate for instance) Processing Delay Delivery Delay Transmission Delay Proprietary & Confidential—Page 39

  40. Latencies (cont.) • Every test environment, closed or open loop, will have some latencies from the time the motion data is sent from the remote system to the time that it is applied on the RF • This can be mitigated however by transmitting remote motion data prior to the epoch which they relate as described below • This is generally only possible in the open-loop case, where data is being read from a file, either located on the SimGEN PC or being delivered via the SimREMOTE interface • The latency could be defined as the delay between the time-stamp of the sample and the simulation time when that position is actually represented accurately at RF • In this case, the latency would be zero, as the data is known in advance and delivered early, so SimGEN can ensure it is applied at the correct epoch Sim Time T(n) Sim Time T(n+1) Sim Time T(n+2) Motion Data T(n+2) Motion Data T(n+3) With Time Stamp T(n+2) With Time Stamp T(n+3) Proprietary & Confidential—Page 40

  41. Latencies (cont.) • Thus if the remote system can provide motion data sufficiently in advance in order for SimGEN to process and deliver the data, then there are effectively zero latencies in the simulation • Some test environments however, such as closed loop environments, may not be able to provide consistent, early motion data • Using a proprietary method, SimGEN can still provides consistent motion data at the right intervals by using the most recent remote motion data to predict the next epoch(s) of motion data output as described below Received Motion Data T(n) Sim Time T(n) Sim Time T(n+2) Sim Time T(n+1) Uses the Accel and Jerk terms from T(n) to accurately predict the motion data output at T(n+2) Predicted Motion Data T(n+2) RF Output Proprietary & Confidential—Page 41

  42. Latencies (cont.) • The effectiveness of this method depends upon the derivatives provided (i.e. Accel and Jerk) and if they are mathematically consistent with the position (e.g. that the Jerk integrates down to the position) • Inconsistent data can cause large pseudorange Accel and Jerk terms to be applied, which would result in an element of “jitter” to be introduced on the RF output • In the worst case the expected levels of Accel and Jerk may exceed the allowed dynamics of the simulator and would be clipped (this normally gives a coefficient over-range error reported in the SimGEN Message Window) • Such effects on the RF output are temporary however and do not degrade the long-term accuracy of the simulator • Thus, it is important that the data be as “clean” as possible to ensure a consistent, accurate representation at the RF output throughout Proprietary & Confidential—Page 42

  43. Agenda • Hardware-in-the-loop (HWIL) testing overview • SimREMOTE setup and interfaces • Remote scenario control and monitoring • Remote vehicle motion • Timing and latencies • Integration considerations

  44. Interface Considerations • TCP/UDP • The SimGEN software acts as a server and the remote program as a client • For all TCP/IP ASCII remote commands, a read command must be executed after each individual command write by the client • This is not applicable to UDP motion data where the client can just write the commands without reading the responses • When using the TCP/IP Ethernet interface, timing uncertainties arising from conflicts can be avoided by using a dedicated network but there is still a problem with small messages which may be held for up to 200 ms by the transmitting PC • This can become apparent during scenario preparation, as a sequence of short commands has to be transmitted • Additionally, if connected to a network, network traffic can reduce SimGEN performance and timing from late or missed messages • For instance if there is a corporate PC backup initiated or anti-virus scan across the network which can reduce throughput and timing Proprietary & Confidential—Page 44

  45. Interface Considerations (cont.) • TCP/UDP • Ideally the remote system would give SimGEN a chance to get the data and process it prior to the desired epoch • So 1 epoch early is fine as long as it really is one epoch • If the data isn’t available at each epoch because of variability in the transmission, then sending the data in 2 epochs early may provide better results • The maximum that a remote system may send the data in early depends upon if the remote system is using UDP or TCP. • If using TCP, then the remote data can be in advance by 400 ms before SimGEN will block the remote system call and remote system will have to wait until SimGEN is within 400 ms of that motion time to return its result • If using UDP, then anything up to 6 seconds can be achieved Proprietary & Confidential—Page 45

  46. Interface Considerations (cont.) • RS-232 • Supports ASCII remote commands only, so a read command must be executed after each individual command write by the client • Spirent recommends using the RS-232 interface with a high baud-rate if possible • Do not use the RS-232 interface high data throughput is needed • IEEE-488 • Supports ASCII remote commands only, so a read command must be executed after each individual command write by the client • The IEEE-488 protocol is free of the delays that may arise with TCP/IP, and, although the data transmission speed is much lower, it remains sufficient for SimREMOTE based systems Proprietary & Confidential—Page 46

  47. Interface Considerations (cont.) • SCRAMNet (Shared Common Random Access Memory Network) • Uses the SCRAMNet protocol of writing commands to specific addresses and reading responses from SimGEN from other addresses • SimGEN does not support “burst mode” • In addition to commands and responses, the remote client can configure SimGEN to send truth data to SCRAMNet addresses for reading • Configuring the SCRAMNet interface requires setting the SCRAMNet node ID and the SCRAMNet memory offset if required for shifting the commands and responses address locations • Optionally it can be configured to use big-endian format to swap bytes of data written to SCRAMNet for interfacing with big-endian systems Proprietary & Confidential—Page 47

  48. Interface Considerations (cont.) • The default protocol defines two areas of memory, one for SimGEN Commands to be written to, and one for SimGEN to write Responses into • These are controlled by two flags: “busy” and “new” • By default, the “command” area of the memory is near the beginning of the SCRAMNet memory • 4000 bytes of space are allowed for commands and the “response” area follows immediately after • Addresses are also available for data streaming of truth data Proprietary & Confidential—Page 48

  49. UUT sending position, velocity and attitude data to a remote system Simulated GPS and Inertial data to the Unit Under Test (UUT) Synchronized with the 1PPS SimGEN data streaming for transmitting status and truth data Remote interface used is Ethernet Putting It All Together • Using the various remote test methods, an example remote test environment is described below Remote system Simulation director for running and stopping simulation Remote system Motion Generator sending UDP motion vehicle data to SimGEN Remote system Data sync for possible real-time comparison of truth and UUT data Proprietary & Confidential—Page 49

More Related