Choosing an SDK for DSLink Development
THe DSLink allows to publish and subscribe to the DSA Broker. The development of the DSLink or microservice is performed using a DSA SDK, and there are many to choose from. There is no specific recommendation for a developer to choose, that will depend on the specific programming language skill set or the desired platform requirements. For example, the JAVA SDK allows for portability across platforms as long as the underlying system supports the JAVA VM, but the memory footprint is a bit larger and may be a factor on small edge devices. In contrast, the C++ SDK allows for a binary has a smaller footprint than JAVA and demands less memory resources.
The SDKs are functionality similar, but might present some differences in each implementation. Currently all the DSA SDKs are open source, but the DSA C++ SDK has been developed and is maintaned by Cisco.
The current DSA SDKs available are the following:
Additional Documentation on DSLink Development
Additional documentation can be found at
Building an object model for sensors to allow for device discovery
We recommend that the DSLink node structure be thought out so that it enables device discovery, as well as making easier onboarding process with use of the Cisco EFM Asset Manager.
The current state of DSLink development is that any developer exposes their devices, attributes and metric readings in an arbitrary tree of DSA Nodes any form.
This leads to a lack of consistency and adds complexity for solution developers as well as DSLink developer. It is hard to understand, discover and use the exposed data in a systematic manner across many message brokers – especially when more than one DSLink is involved in a solution.
Much unnecessary effort is spent and experience is needed to clean up and transform the data into a useful common structure which is easily usable for dynamic queries.
Rather than every developer proposing their own node structure and every solution developer having to think through the complexity of many use cases, even the potential future protocols not in use, we are proposing an object model that allow for a DSLink to expose device, their attributes as well as metrics in a standard manner.
By providing a standard structure, we enable:
- Faster development of solutions
- Generation of new tools that discover and consume telemetry data without great efforts
- The automatic discovery of devices/assets – for example by the central EFM Asset Registry Database – even if they have been moved around.
- A significant effort reduction for the adaption of software solutions in the case that a new device driver DSLink should be added to a solution
The Asset Registry Service + Database
The EFM Asset Registry is a software component introduced with EFM 1.5 into the Edge and Fog Module. It is a central database of known assets across all (interconnected) DSA brokers of an EFM installation. The assets inside the asset registry have a strict data schema which is specific for each asset type and therefore provides a well-organized logical view of all the sensor assets inside a DSA Broker Network.
The asset registry exposes this central database through its own web interface. Inside this user interface end users and administrators are able to see a list of all device/sensor assets - no matter on which DSA broker their managing DSLink exist.
The Device Node Discovery Process
The device node discovery process runs as a background process inside the Asset Registry. The discovery process is responsible to detect new appearances of DSA nodes which represent a physical device.
To make this possible the EFM team has defined a few declarative DSA properties which your protocol DSLink has to maintain inside DSA nodes that represent an onboarding capable device (in most cases a physical or logical sensor device).
The actual DQL query which will be used to find the occurrences of a certain sensor type is part of the device-type specific onboarding definition inside EFM. Here is a potential example of such a DQL search query:
It is important that DSA nodes that represent a device which should be detectable/discoverable by the asset registry have declarative properties that can be used in such a DQL query.
Asset Acceptance
While not part of the sensor asset object model, the acceptance process allows in the EFM Asset Manager allows to add a sensor into the Asset Registery Database. It also allows for for the definition of additional meta inputs that can be input by the administrator at time of acceptance. These fields can be optional or mandatory, as defined by the templates. For example, additional fields can be the service contract, physical location, support contact, etc. The manner in which this is defined is in the onboarding configuration templates for the EFM Asset Manager. See the EFM Asset Manager User Guide documentation, in the section Creating user Onboarding Definition files using the Onboarding Definition Templates.
The EFM Normalized Assets DSLink
This Cisco developed component exposes a DSA interface that is being used by the Asset registry to publish the list of normalized assets and their dimensions into the DSA world.
The Normalized Assets DSLink is therefore the aggregation point where device data from multiple Device Driver DSLinks can be consumed by other DSA Subscribers in a convenient flat way.
The intention of this DSLink is that most data consumers (no matter if they are interested in fast changing telemetry data or in slow changing structural dimensions) will subscribe to the DSA Children of the Normalized Assets DSLink and not directly to the Device Driver DSLinks child nodes.
Is there an example DSLink which implements this Object Model?
Yes, an example DSLink implemented in Java which simulates Vibration Sensors and Temperature Sensors is available and a part of the EFM software package. It is possible to use this DSLink in conjunction with the EFM Asset Manager to discover and accept sensors, get familiar with the process, user interface, the resulting node structure of the simulated devices.
Additional reference material
For further information on the recommended sensor object model, please refer to the detailed article EFM Device Driver DSLink Development Standard Documentation. For the EFM Asset Manager onboarding documentation, the latest user guide can be found on CCO.