LNI 4.0 Testbed Edge Configuration Implementation View
The testbed Edge Configuration was established to prepare the standardization in the context of the manufacturing industry with respect to the emerging edge computing technology. The testbed does not address edge computing technology in itself but focuses on edge configuration. For this purpose, con-cepts will be developed, practically implemented and validated. The results and experiences will be made available to the standardization activities to feed them into the further or new development of standards. From an architectural point of view, the testbed Edge Configuration is based on a layered architecture as shown in Figure 1:
Figure 1. Layered architecture of the proposed testbed Edge Configuration
The focus of the testbed Edge Configuration is on the configuration of the interaction between the field, edge and edge management layer. Currently there does not exist a suitable standard for this focus and the testbed will develop proposals for this aspect. Based on the functional primitives including parameter sets in the functional view, this document (implementation view) will provide a framework for formal REST-API interface specifications that can be directly implemented on IT relevant protocols like HTTP, MQTT or OPC UA. This formal specification shall be provided in form of JSON-based data models, objects and semantics.
In order to derive implementation specifications, the functional requirements identified in the Functional View document [4] are systematically analyzed and formal interface specifications for procedure- and event-based interactions between the architectural components provided that can be directly imple-mented on suitable IT relevant protocols like HTTP, MQTT or OPC UA. The formal specification shall be provided in form of JSON-based REST-API data models, objects and semantics. The definitions shall provide a standardized outer frame, thus only the URI addressing scheme, the basic access endpoints and some top-level structure definitions for the response data objects shall be defined and recommended. Detailed variable definitions in the provided examples are just for demonstration purposes and not intended to be binding for implementation.
To reduce the number of REST-API endpoint definitions, Field and Edge Devices are considered as a single class of devices whenever possible. For example, in the case of device parameter retrieval, the interface for a Field Device is identical to that of an Edge Device.
To cross-check against the functional view definitions, the sequence diagrams created there are very helpful. For every activity that is started for an object instance in the sequence diagrams, a corresponding interface description must be available in this implementation view.
In order to avoid compatibility issues in the future, encoding version information into the URL addressing the API endpoints shall be avoided. Instead a specific base endpoint shall return the version information of the current implementation.
Asset addressing is depending on the Discovery and Directory Service and should be mapped to standardized identification properties. Asset adressing for hardware assets as defined in AAS.