Goal
Produce a more dynamic dummy plugin that can be used to generate complex testing scenarios.
Requirements
- Support an unlimitted number of simultaneous handlers
- Be thread safe
- no static structures used in writable mode
- Be easy to extend (adding new RDRs or Resources)
- to this end we should issolate one .c / .h file per functional area (sensors, controls, power, etc)
- Provide entry points for modifying live data (RPT, event injection, etc)
- Be a lot more readable than current dummy
Design
The purpose of the Simulator Plugin is to, as closely as possible, simulate a real hardware device. It should support at least one of every type of resource specified by the HPI B specification, and in most cases, support a variety of resource types from each specification category. This will ensure that the core OpenHPI code is completely exercised.
In order to accomplish this goal and make the use of the plugin as flexible as possible, the plugin will be composed of two parts. The first part will be the basic plugin code which will look very much like a traditional plugin which supports a real hardware device. The biggest difference will be the method used to communicate with its "hardware".
The second part will be software which simulates a hardware device. The design for this simulated device should allow for it to either support the full set of resources specified by the plugin or to support a subset of those devices. This will allow the maximum flexibility for testing interactions between pairs of resources without side effects from other resources.
The overall design should take the following form:
+--------------------------+
| |
| OpenHPI |
| |
| +--------------------+ | +----------------------+
| | | | | |
| | Simulator Plugin | | | Hardware Simulator |
| | | | | |
| +--------------------+ | +----------------------+
| |
| +--------------------+ |
| | | |
| | Other Plugins | |
| | | |
| +--------------------+ |
| |
| |
+--------------------------+
At this point, it has not yet been determined if the Hardware Simulator will be contained within the same process as OpenHPI or if it will be in a seperate process. In any case, a communications mechanism between the Simulator Plugin and the Hardware Simulator will need to be created. The communications mechanism should be a simple as possible and does not have to be a network-based protocol.
Simulator Plugin Design Details
The architecture of the Simulator Plugin should contain these elements:
- The plugin should support a vast array of resources. It should be noted that the hardware Simulator may or may not support all of the resources specified by the plugin. In fact, in most cases the hardware simulator will only support a limited subset of the potential resources.
- The plugin should support at least one resource of each type of resources specified by the HPI B specification. In most cases it should support multiple types i.e. a read only sensor, a read/write sensor, etc.
- The plugin should make every attempt to look as if a real hardware device is actually supported. If state information about the hardware is needed it will communicate with the Hardware Simulator to obtain the information and not cache it locally. The same is true for writing state information to the
"hardware".
- The list of resources supported by the plugin should be coded in such a way that they can be shared with the Hardware Simulator code.
Hardware Simulator Design Details
The architecture of the Hardware Simulator should contain these elements:
- The list of resources supported by the Simulator Plugin should be selectable by the Hardware Simulator so that it can support subsets of potential resources.
- Hardware state information should be completely maintained for each supported resource.
- Where possible, state information should be kept in the defined HPI structures from the standard header files.
- An API should be available to support injection of events to the OpenHPI plugin/system. This also implies that the user should be able to supply a list of events to be injected into the system once OpenHPI discovery has been accomplished.
- The communications mechanism between the plugin and the "hardware" should be as simple as possible. Linux queues or pipes are potential candidates for this mechanism as this would allow for passing binary information and HPI structures.
Coding the Hardware Simulator as a seperate process has some additional benefits.
- All the features of the Hardware Simulator could be available as an API. This would allow an application to wrap the "hardware" to provide dynamic mechanism like event generation.
- Creation of a batch mechanism for testing purposes would be simpler.
The potential for specifying the resources supported by the Hardware Simulator would be easier and involve fewer compile and link steps.