The OpenWMS.org OPCUA Driver component is designed and realised to work with OPCUA compliant counterparts acting as an OPCUA Server.
The OPCUA architecture follows the traditional Client-Server Architecture (CSA) where a client connects to a server in order to exchange messages.
With OPCUA two connectivity methods can be used basically. Either direct point-to-point or through a discovery service.
Read more information about the OPCUA Discovery Service here:
In the current version three protocols can be used for transferring messages: TCP/IP Sockets, HTTPS, WebSockets
A client, in the context of projects realised with OpenWMS.org, is always the OpenWMS.org application. The OPCUA server is either the direct IPC/PLC or a middleware (so called DACO - DAta COncentrator). Defined by the OPCUA specification a client has four options to communicate to a server:
The OpenWMS.org Common Service provides essential functionality to deal with Locations, LocationGroups and TransportUnits. An example often referred to is the ability to move a TransportUnit from a Location A to a Location B. Beside this also other secondary resources like TransportUnitTypes or rulesets like the PlacingRule to define what kind of TransportUnit can be put on what type of Location are managed by this service.
The required and demanded functionality of the Common Service is comprised by the issues tracked in GitHub issue tracker. All open issues that are assigned to an upcoming milestone are accepted for implementation and will likely be implemented and released.
Open pending issues
| Issue ID | Planned Milestone | Title |
|---|---|---|
3.0.0 |
Migrate to SpringBoot 3.2.5 |
All functionality that is currently included, has already been implemented have issues assigned that are closed. A list of all closed issues with their resolved milestone release is shown below. Notice that issues may be closed but the implementation has been rejected.
Closed issues, either implemented or rejected.
| Priority | Characteristic | Scenario | Activity | Risk |
|---|---|---|---|---|
HIGH |
Interoperability |
The service must be operated in a service mesh of services of arbitrary technologies |
The service API is implemented with HTTP and JSON exchange format |
— |
HIGH |
Performance |
The service must respond in less than 100ms |
This needs to be considered with the choice of the persistency mechanism |
Scalability: Increasing datasets could have an impact |
MEDIUM |
Accessability |
The service may run in a multi-tenant environment and all functions must be aware of multi-tenancy |
All API functions, services and persistency mechanisms must be aware of the tenant |
Performance: With increasing tenants this could have a negative impact on the performance with regarding data isolation |