...
- What types of device are supported.
- What protocol features are supported / likely to be supported in future.
- What limitations does the existing implementation have.
- What hardware and software has it been tested against.
A brief demonstration of the device service in operation may be helpful.
If the WG approves, a repository in the edgexfoundry-holding project will be created, for the new service to be imported into. The WG will also seek volunteers to form a review group, who will consider the service for suitability once it is imported. The creation of a review group and its membership should be recorded in the WG meeting notes.
Other than general code quality, the review should consider:
- The service should implement the functionality described in the Device Services Requirements document.
- The service should target either the current or development versions of EdgeX.
- The service should not rely on new or variant APIs.
- The service's name should should follow the usual form, ie edgex-{device-class}-{language} and not conflict with any other adopted service.
- Values must not be hardcoded where they might reasonably be configurable.
- A top-level README should be present and contain information on
- The types of device supported
- Host device requirements, especially if advanced features or operating modes are needed.
- Run-time dependencies
- Protocol feature support and roadmap
- Known limitations
- Information on asynchronous readings, if these are generated
- Build instructions, including build-time dependencies
- Usage information (command-line options)
- The following items must also be documented:
- Supported configuration options .(including whether or not the service must be restarted for changes to take effect)
- Supported ProtocolProperties schemes.
- Supported Device Attributes.
- As part of the above, example Device Profiles and illustrative TOML for Device provisioning should be included.
- It must be possible to run the device service against simulated hardware. Documentation illustrating how to do so is also required. The review group should attempt to replicate the scenario described.
- Container packaging must use full confinement (i.e. no use of docker --privileged or snap --devmode). Where access to hardware is required, care must be taken to make exceptions for the specific required hardware and/or system resources, and the means to allow these exceptions should be documented.
- The service should comply with the general EdgeX requirements as given in the Contributor's Guide.
...