The system architecture

- [Narrator] Because, we're dealing with a wide variety of IoT devices, a general device management solution needs to work across IoT platforms. Such as hardware platforms, like single-board computers or other embedded system boards. And operating systems such as general purpose and embedded operating systems. Note that it's possible to have a DM solution without an OS. Let's look at architecture for a DM software solution first. We can implement everything regarding DM for each device platform which, is difficult to make the solutions scare easily. Or, we can decouple some high-level DM functionalities from the device specific hardware and OS operations, as shown in this diagram. As a first step to make the DM solution work across different platforms. Following this approach, we can consider the DM solution as an M2M solution running on the computers or devices across a communication network. Mostly IP based network, such as Internet which can be seen in this diagram. Where, the essential parts are shown here. Such as, DM application endpoints, message transfer protocols, and device platforms. Which indicate a specific OS and hardware platform. We can view this architecture into three layers. Where we consider DM applications implementing the DM functionalities are put into the DM application layer. The message transfer protocols which provide direct message transfer services to the DM application layer or at the communication protocol bindings layer. And the other underlying network services and the connections are put at the underlying communications network layer. Most of DM solutions adopt the client server model which means, a DM application usually has two entities. The first entity is the DM software agent. Running on devices being managed as DM clients. And, the other entity, is the DM central controller. Running on the local or remote DM server's endpoint as DM server. We can have multiple DM clients and multiple DM servers. And in this way, this end-to-end solution is flexible to fit many use cases. Let's see how a DM client application , called DM agent for short here, interacts with the DM server application. The DM agent can manage resources on devices as shown here. Virtualizing the devices in terms of a structure of essential resources, in terms of, metadata and digital objects regarding the management of IoT devices. Such as, device info., formal version, location, etcetera. Where a DM server application endpoint can access them remotely. The DM agent also does interfacing with the DM server. For example, if your application is running on the Linux OS, the DM agent running on top of it considered is software agent which can take remote commands. Evoke OS related commands. And interact with other DM entities like Cross and Internet. For example if the DM agent is receiving a firmware update command from a server, it will securely identify and download the new firmware image, evoke a series of OS commands to do the update operations. And then, send the results out to indicate whether the operations is successful or not. This way, we can see that the DM agent provides an interface to do the operations on a device. And, at the same time, interact with other entities involving in a DM process. We can easily implement or use the same DM agent with a different OS. For a DM solution implemented with Java or Python, you can easily expect that to work on many platforms. We'll see standard based device platform agnostic DM solutions implemented with Java later. The DM server application endpoint as a controller performs the DM related operations in a centralized way. Providing DM service amongst other services on a remote server. Or, on the cloud. Therefor, if putting things together, we have a general architecture for a DM system. Although, there can be other components added. Such as, security gateways sitting on or in between the end devices in a DM server. The M2M ends users who can be the subscriber to the DM application's services based on the basic DM's services. With the general system architecture for a DM solution, there are some key actors we need to understand. They are: applications service provider, who provides services to the M2M end users. These can be the device manufacturer or, a 3rd party service provider. M2M service provider itself, who provides the key M2M services to be used by all thoughts of application services. Network service provider, who provides underlying network connectivity and related services. And M2M end users, who use or consume the M2M application services or other services.