CAN Simulator

The technical details on this page are for the CAN Simulator. The CAN Simulator runs as a stand-alone process and sends CAN data through a socket when an app connects. CAN simulation is accomplished through either a Java CAN Panel with sliders or a Vehicle Spy script. The CAN signals available for simulation are found in a Sensor Properties file. The Sensor Properties file should be the same Sensor Properties file used by the Sensor Container.

The source code as well as the diagrams shown on this page are available in the Emulator & Simulator section of the Developer Software page. If you make any improvements please send them to FCA so we can provide a better tool for everyone to use.

You can send improved source code to mark.schweiger@external.fcagroup.com or andrew.hoin@fcagroup.com.

Contents:

Simulation Overview
Class Diagram
Scripted Sequence Diagram

Simulation Overview

 

  1. The method used to start the CAN Simulator determines if it will use the Java CAN Panel or a Vehicle Spy Command Script to control the simulation. Passing a Vehicle Spy Command Script as a parameter will run the simulator in the script mode.
  2. On start the simulator will look for the simulator properties file in the properties directory where the app jar was executed from.
  3. The simulator will get the location of the sensor properties file from the simulator properties file, read it, and then parse it to get the sensor to CAN signal mapping, the sensor return value, sensor data range, and resolution.
  4. The parsed sensor values will be stored within the CAN Simulator in a database. The database is a HashMap of sensors and sensor attributes.
  5. After the database of signals is loaded the simulator opens a socket and waits for an app to connect.

Top
Back to Technical Details

Class Diagram

 

The CAN Simulator classes and descriptions.

  • SimulatorMain, contains the main class for the simulator. It is responsible for parsing the command line arguments, creating and the correct simulation, and starting the simulation.
  • SimulatorProperties, encapsulates locating, retrieving, and loading property files for CAN simulation. SimulatorProperties looks in the properties directory where the simulator was started from to retrieve the properties file.
  • Simulator interface, defines the method to start the simulator.
  • SimulationController, defines additional control methods for the simulator as well as responsible for starting the signal server on its own thread.
  • HMISimulator, implements the control methods in SimulationController and Simulator for the Java CAN Panel simulation.
  • SimulatorPanel, is a Java JFrame and is responsible for building the sliders in the GUI. The slider attributes are sent to the SimulatorPanel from the parsed sensor properties.
  • ScriptedSimulator, implements the control methods in SimulationController and Simulator for the Vehicle Spy command script simulation.
  • SignalServer, parses the sensor properties file, uses the parsed sensors to initialize the SignalDatabase, then starts a process loop reading and writing from a socket until the connection is terminated.
  • SignalDatabase, is responsible for maintaining the sensors defined in the sensor properties file and the associated simulated sensor values. The SignalDatabase is also responsible for notification to any registered listeners.
  • SensorPropertiesParser, is responsible for reading the sensor properties json file and creating an array of sensors and their attributes.
  • Write, Read, Response, Terminate, and Listen, are serializable classes that sent over the socket used by the simulator to communicate with a client.
    The Write object is used to write or update CAN signal data.
    The Read object is used to read or retrieve all of the sensors for a sensor source.
    The Response object is used by a CAN Simulator client to retrieve sensors and sensor values from the CAN Simulator.
    The Terminate object is used to notify the CAN simulator to shutdown.
    The Listen object is used to notify the CAN simulator that a client is interested in any updates to a sensor source.
  • SignalServerListener, defines server state notification.
  • PanelController, not currently implemented.
  • ScriptController, is the scripted mode listener for the signal server. The scripted process needs to know when signal server has started so it can start sending the simulated CAN signals.
  • ScriptHandler, is responsible to parse the the commands in the scripted simulation and then runs the simulation.
  • CommandHandler, collects script commands and simulates the execution in the script.
  • SimulatorCommand, is a container for a simulator command and the command value.

Top
Back to Technical Details

Scripted Sequence Diagram

 

This sequence diagram represents sensor data change and retrieval events for the CAN Simulator when running in scripted mode. The sequence diagram has been abstracted to a high level view to facilitate understanding of the concept.

  1. SimulatorMain starts when the CANSimulator jar is excuted.
  2. SimulatorMain instantiates ScriptedSimulator if a Vehicle Spy script was entered as an input argument and executes the start method.
  3. The ScriptedSimulator starts the SignalServer on its own thread.
  4. The SignalServer retrieves the location of the sensor properties file and requests the SensorPropertiesParser to parse the json sensor properties file. The sensor properties are parsed into an array of sensors to simulate.
  5. The array of sensors to simulate is sent to the SignalDatabase where each sensor is stored.
  6. The SignalServer is now ready to run the simulation and creates a socket and waits for a client to connect.
  7. The App W/Emulator can now connect to the socket. The app retrieves CAN data using the Kona sensor implementation. the Kona sensor implementation uses the SensorContainer component as the client for the CAN Simulation. The SensorContainer handles all of the socket communication.
  8. Once a client connects to the SignalServer socket the SignalServer notifies the ScriptController to begin the simulation.
  9. The SignalServer goes into a request response loop handling all requests and responses through the socket.
  10. The ScriptController gives the ScriptHandler the array of sensors to simulate and starts the script process on a separate thread, Script Handler Thread. The Script Handler Thread is started to allow the ScriptHandler control over the script process as well as allow Script Handler Thread and the Signal Server thread to run concurrently performing different tasks.
  11. Once started the ScriptHandler creates a new CommandHandler and adds commands it parses from the Vehicle Spy script. Currently, there is support for an add and a sleep command. Add will add a new signal value as found in the script and sleep will cause the script process to wait before sending the next command. Sleep simulates the interval between CAN signals.

    Not all of the CAN signals are parsed from the Vehicle Spy script as an app may not need all of the CAN data in the script. The signals to simulate are controled by the filter property, ScriptHandler.signalFilter found in the CANSimulator properties file.

  12. After all of the commands are parsed from the Vehicle Spy script the ScriptHandler asks the CommandHandler to run the commands. This starts the simulation.
  13. The simulation will iterate through the command list the number of times specified by the CommandHandler.maxRunLoopCount property. The CommandHandler will write a CAN signal and its value to the SignalDatabase.
  14. The SignalDatabase is responsible for notifying the SignalServer through the ResponseEventListener that CAN data has changed.
  15. The changed CAN data is sent to the client through the socket.

Top
Back to Technical Details

Updated: 03/13/2017