Script language software

Script language software

research simulator script language

Scenario Script Language is the specification language designed by ourselves to define any number of scenarios. The term ‘scenario’ should be considered very broadly. The language was already designed in the 90-ties and has been the inspiration for a number of script languages in research simulators of other manufacturers.

The user defines the simulations, lessons or experiments in this script language. Before it is applied in the simulator, it is compiled into binary form and the script compiler checks for syntactical errors. The language is fully documented, and the research simulator software module comes with a large number of script examples.

Each scenario scripts defines a start condition and an end condition. The start condition specifies when the scenario starts. The end condition defines when the scenario ends. Any condition can be used to start a scenario, for example, when you are on a specific path (road) on a certain distance to the next intersection, or when your velocity is larger than 5 km/h, when the headway to the leadvehicle is less than 2 seconds, etc. This makes the definition of any experiment very flexible. It also makes use of the real time dynamical situation that changes from second to second.

Any number of scenarios can be defined and scenarios can also be defined in include files that contain functionalty that can be reused. So at any moment, a large number of scenarios can be active simultaneously. Some scenarios may generate traffic, other scenarios may check if a verbal message or a graphical image must be presented to the subject, other scenarios may communicate with an external computer via ethernet, and others may be involved in datasampling or data analysis. The script language contains a very large functionality.

Functionality of the script language

Apart from scenarios to define all things to run simultaneously, there are a lot of other things you can define in script. Examples are:

  • There’s a large set of system defined functions and procedures. For example, functions to get the brake pedal position, steering wheel angle, rpm, fuel consumption etc. and procedures to send a speech message to the sound scheduler, or a certaing amount of sidewind to the simulator vehicle. This also includes functions and procedures for data communication via ethernet, data analysis, etc.
  • The user can define functions and these can be used to store as data, in a condition as a criterion to start or end a scenario etc.
  • Each scenario can have any number of actions that operate as a state machine.
  • Each traffic participant can have his own scenarios attached so only this vehicle does things in a certain order. For example, this allows a definition such as: if I am less than 2.5 seconds behind a lead vehicle and if this vehicle is in the same lane as I am, it first starts to decelerate with a certain maximum deceleration until its speed is 20 km/h lower, then it drives on for 3 seconds, and then it accelerates again. In the mean time record the minimum of TTC and the maximum brake pedal position and store this to an external file.
  • Paths, road segments, traffic participants, intersections etc. are all different types of objects that have their own data and functions that can be modified (unless they are fixed) and accessed. This allows you to precisely define traffic behaviour and use al these data in your own functions and in conditions in scenarios.