Sensor Container

The technical details on this page are for the Sensor Container. The Sensor Container was designed to communicate with the CAN Simulator over a socket. It is responsible for collecting the changed sensor data and notifying any app listening to the sensor that the data has changed. The Sensor Container has been integrated into the sensor package in the Kona Emulator.

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:

Sensor Container Overview
Class Diagram
Sequence Diagram

Sensor Container Overview

 

  1. The Sensor Container is a Singleton implementation and on instantiation will look for the container properties file in the properties directory where the app jar was executed from.
  2. The container will then connect to the CAN Simulator socket and request the CAN Simulation to send all simulated sensors and their values.
  3. If no listeners have been requested the container will read all of the sensors for a sensor source for each sensor data get request.
  4. If one or more listeners have been registered the container will start a new thread to monitor any updates from the CAN Simulator. If updates occur the thread will notify any listeners that have been registered.

Top
Back to Technical Details

Class Diagram

 

The Sensor Container classes and descriptions.

  • Write, Read, Response, Terminate, and Listen, are serializable classes that sent over the socket to the CAN Simulator.
    - The Write object is used to write or update CAN signal data.
    - The Read object is used to request retrieval of all the sensors for a sensor source.
    - The Response object is used by a CAN Simulator to send a response to the container.
    - 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.
  • SensorContainer, manages sensors grouped by a sensor source. There is currently only one sensor source (can/xlet). The SensorContainer communicates with the CAN Simulator through a socket requesting sensor values or asking to be notified when a sensor's value changes.

    The SensorContainer uses an update Thread to monitor CAN Simulator updates and send update notifications to the registered listeners.

  • ContainerProperties, encapsulates locating, retrieving, and loading property files for the SensorContainer. ContainerProperties looks in the properties directory where the container was started from to retrieve the properties file. This will be the directory your xlet was started from.
  • SensorSource, is the source of the sensor data. There can be many sources for sensor data, however the current implementation only supports one, (can/xlet).
  • Sensor, is the application's proxy to a CAN signal. A sensor is identified in the sensor properties file as a component. Each component or sensor is mapped to a CAN signal or PPS Attribute.
  • SensorListener, supplies notification that a change was made to the sensor.

Top
Back to Technical Details

Sequence Diagram

 

This sequence diagram represents sensor data retrieval events for the Sensor Container. The sequence diagram has been abstracted to a high level view to facilitate understanding of the concept.

  1. Get Sensor Connection an application requests a new kona sensor connection.
  2. When a new sensor connection is requested an instance of the SensorContainer is created if it does not already exist.
  3. When the SensorContainer starts it will connect to the socket that the CAN Simulator started.
  4. The Container creates a request to read all the simulated sensors for the default sensor source (can/xlet). This is only done when a new Container is instantiated.
  5. The read request is written to the socket's output stream.
  6. The input stream is read for the response from the CAN Simulator containing the simulated sensors and their values.
  7. The sensors and their values are then parsed from the responses byte array.
  8. All of the sensors are added to a new sensor source.
  9. A new sensor is created for each of the sensors added to the sensor source.
  10. Each of the sensors added to the sensor source and their values are updated.
  11. All registered listeners are notified of the update to the sensors' value.
  12. Add Data Listener, an application registers to receive notification when the data associated with a Kona sensor changes.
  13. The Kona emulation registers the listener with the sensor.
  14. The Sensor lets the SensorSource know that one of its sensors are being listened to.
  15. As there are now listeners for sensor updates the sensor source will request the container to start monitoring updates.
  16. The container will start another thread to monitor updates leaving the container free to handle other requests.
  17. The new update thread notifies the CAN Simulator that a listener has been registered for a sensor by creating a Listen request.
  18. The listen request is written to the socket's output stream.
  19. As long as there are listeners registered the Update Thread will read the input stream for a Response containing updated sensor values.
  20. When a Response is found on the input stream the sensors and their values are then parsed from the responses byte array. The CAN Simulator responds to each signal change by sending all signals contained in the sensor source.
  21. Each of the sensors and their values are updated.
  22. If a sensors value has changed then update the sensor.
  23. If any listeners are registered for the updated Sensor they are notified of the change.
  24. Get Sensor Data, an application requests the Kona emulator to get the data associated with a sensor.
  25. The Kona emulation requests the data from the sensor.
  26. If the container is monitoring updates then the sensor returns it's value. If the container is not monitoring updates (there are no listeners present) then the container requests the sensor to be udpated by creating a read request.
  27. The read request is written to the socket's output stream.
  28. The socket's input stream is read for a response.
  29. When a Response is found on the input stream the sensors and their values are then parsed from the responses byte array. The CAN Simulator responds to each signal change by sending all signals contained in the sensor source.
  30. Each of the sensors and their values are updated.
  31. If a sensors value has changed then update the sensor.
  32. If any listeners are registered for the updated Sensor they are notified of the change.

Top
Back to Technical Details

Updated: 03/13/2017