This note outlines the process by which a contributed device service may be adopted into EdgeX. Consideration will generally be given to services which provide access to classes of devices previously unavailable in EdgeX, or which have substantial advantages over an existing implementation.

In the first instance, the contributor should contact the working group chair to arrange a date on which consideration of the new service may be added to the WG agenda. At the arranged meeting, the contributor should give a short presentation on the new service and take questions. The working group will likely be interested in:

• What types of device are supported.
• What protocol features are supported / likely to be supported in future.
• What limitations does the existing implementation have.

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.

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.
• The following items must be documented:
  • Supported configuration options.
  • 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 service should comply with the general EdgeX requirements as given in the Contributor's Guide.

In some cases a review may take place in a number of cycles, eg if the reviewers feel that one or more fundamental issues need to be addressed before detailed consideration is worthwhile. Where the reviewers feel that changes are necessary, issues should be created within GitHub for discussion and resolution. During the review process, other contributors may raise issues of their own; it is not compulsory that these are resolved but the review team should consider them before giving overall approval.

Should the review of the service be successful, a unique default listening port will be assigned for the service, and the WG chair will propose to the TSC that the service be adopted into EdgeX.

If the TSC agrees, the following actions need be taken:

• The service code is moved from -holding to the main edgexfoundry project.
• EdgeX documentation is updated to include the new service.
• Required devops infrastructure is put into place.
• Release artifacts for the first version should be generated and published.
• Device WG wiki pages to be updated.