Kona Emulator

The technical details on this page are for the Kona Emulator. The Kona Emulation is an implementation of the Kona interface designed to support app testing. The emulator contains a basic implementation of the current Kona interface. The implementation emulates the radio implementation by providing API return values fed from a properties file where appropriate. The implementation also contains a full sensor implementation that is integrated with the Sensor Container package and thus able to retrieve signal values from the CAN Simulator.

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:

Kona Emulator Overview
Class Diagram
Sequence Diagram

Kona Emulator Overview

 

  1. On the first call to an emulated Kona interface the emulator will read all of the properties in the emulator properties file.
  2. For Kona API calls that can return a simple primitive or Object the return is built from the values in the emulator properties file.
  3. If the xlet requires access to CAN data the emulator implements most of the sensor package interfaces.
  4. The emulated sensor package is integrated with the Sensor Container component which will interact with the CAN Simulator to simulate CAN data.
  5. The sensor package is dependent on the sensor properties file. The sensor properties file location entered into the Kona emulator properties file should point to the same file used in the CAN Simulator so apps do not request sensor from Kona that are not in the CAN Simulator.

Top
Back to Technical Details

Class Diagram

 

The Kona Emulator classes and descriptions.

  • Kona Interface, represents all of the Kona API except the sensor package.
  • Kona Implementation, represents all Kona API calls that can return a simple primitive or Object. The API return is built from the values in the emulator properties file.
  • EmulatorProperties, is a singleton class the reads all of the properties in the emulator properties file. The properties that are used by the Kona API to build return values are keyed with the className.methodName.
  • Sensor Properties, is a json file containing sensor to CAN signal mapping and sensor properties.
  • Kona Sensor Interface, represents the interfaces in the sensor package.
  • Connector, is responsible to create the appropriate connection based on the properties of a sensor. There are two types of supported sensors in the radio implementation. A writable sensor used for things like remote operations and a read only sensor. Currently the emulator only supports a read only sensor.
  • SensorManager, is used to find sensors. The sensors and their properties are built from the sensor.properties file.
  • SensorObjectFactory, reads the sensor properties file and builds SensorObjects from the sensor properties.
  • SensorObject, is the java representation of the sensors defined in the sensor properties file.
  • SensorConnection, is an abstraction of an actual sensor. It provides the ability to retrieve data from a sensor by providing a connection to it.
  • DataListener, provides a conduit to notify an xlet that sensor data changed.
  • Data, is a container for sensor values returned from the Sensor Container.
  • SensorDataManager, is the interface to the Sensor Container. It is responsible for requesting sensor data and setting data change listeners.
  • ContainerSensorListener, provides a conduit for the Sensor Container to provide notification that sensor data has changed.
  • NotificationEventManager, is a singleton implementation that maintains an event queue to handle sending notifications to registered listeners when the listener conditions (signal change or condition met) are met.
  • Sensor Container, is responsible for mapping each sensor to a CAN signal and maintaining the sensors value.
  • CAN Simulator, simulates changing CAN data on a Windows PC.

Top
Back to Technical Details

Sequence Diagram

 

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

  1. Open, an xlet requests a new kona sensor connection.
  2. Find Sensors, verify that the current sensor is in the sensor properties file then gets the sensor properties for the requested sensor.
  3. Get Sensor Connection, a new SensorConnection is created for the sensor.
  4. New, create a SensorDataManager for each connection.
  5. Get Sensor Container, establish a connection to the Sensor Container.
  6. New Socket, the Sensor Container connects to the CAN Simulator through a socket.
  7. Sensors, current sensors and their values are returned to the Sensor Container after a connection is established.
  8. Get Sensor, The SensorDataManager requests the sensor (with it's current value) from the Sensor Container.
  1. Get Data, an xlet requests a sensors value.
  2. Get Data, the SensorConnection requests the sensors value from the SensorDatamanager.
  3. Get Value, the SensorDataManager requests a sensors value from the Sensor Container.
  4. Read Sensors, if the Sensor Container is not monitoring the CAN Simulator data changes then get the sensor values from the simulator before returning the sensor value.
  1. New, an xlet creates a new DataListener to monitor CAN data changes.
  2. Set Data Listener, let SensorConnection know that the xlet wants to monitor CAN data changes.
  3. Set Data Listener, let SensorDataManager know that the xlet wants to monitor CAN data changes.
  4. Add Data Listener, to the NotificationEventManager. The addition of the DataListener or a ConditionListener is an event.
  5. New, ContainerSensorListener is created to monitor sensor udpates from the Sensor Container.
  6. Add Container Sensor Listener, adds the new ContainerSensorListener to the Sensor Container.
  7. Start Event thread, is a new thread that handles events added to a queue. A new thread is only created if an Event Thread is not currently running.
  8. Wait For Event, the new thread waits for an event to be added to the event queue.
  9. Update, CAN data changed in the simultor. If the data changed for a sensor with a listener then call the update method on the listener.
  10. Update, for each sensor connection with a listener there is a SensorContainerListener monitoring the Sensor Container for updates. If the data changed for a sensor with a listener then call the update method on the listener.
  11. Start Listener Thread, creates a new thread for each sensor change in the Sensor Container. The Listener threads only respopnsibility is to add a notifcation event. This thread leaves the Sensor Container free to do other work.
  12. Add Event, adds the notification event to the Event Threads event queue.
  13. Pop Event Queue, handles the next event in the notification event queue.
  14. Data Received, notication is sent if the notification event was a DataListener.
  15. Condition Met, notication is sent if the notification event was a ConditionListener.
  16. Get Data Type, retrieves the type of data sent back. The types are either integer, double, or an object.
  17. Get Value, retrieves the sensor value based on the data type.
  18. Set Value, returns the changed sensor value to the xlet.

Top
Back to Technical Details

Updated: 03/13/2017