Asema IoT Central

Architecture and operation


Chapter 1. Introduction

The Asema IoT Central is a versatile system integration software for Internet of Things projects. It is designed to be an efficient tool that scales without effort from simple one machine data logging applications to heavy-duty service oriented cloud architectures. Unlike the majority of IoT solutions that rely on a heavy middleware architecture, Asema IoT Central is one extendable modular application. The lightweight approach enables running it much more efficiently, with less hardware requirements, easier maintenance, and native capability for edge computing.

Asema IoT Central is meant to serve as a basis for custom application building. The software comes with a range of pre-developed applications that can be used straight out of the box for sensor monitoring, remote control dashboards, product pricing, information displays, etc. The source for all these applications is also included, making it possible to modify, extend and expand them from simple re-branding to full-blown logic customization. We however deliberately want to avoid calling Asema IoT Central a "platform" as that would give the common impression of a heavy system with lengthy development cycles and advanced installation. Asema IoT Central is a solution, not a platform.

The difference between a lightweight, optimized system and a middleware-driven solution is significant: where a Java middleware driven IoT solution easily can take 20-30GB of disk space and require a multicore processor with several gigs of memory, Asema IoT Central with all cloud bells and whistles packs in just under 200MB of disk. It can run with less than 100MB of RAM with full user interface and a mere 12MB in the headless mode that is typical for server installations. A stripped down edge version, Asema IoT Edge, takes about 50MB of disk and runs on a single core embedded ARM taking less than 5MB of RAM. This makes it possible to run sophisticated applications in the form of a grid by installing the system as autonomous instances into inexpensive embedded boxes such as Raspberry Pi or Android and iOS mobile devices. For someone that hosts sensitive data for multiple customers it means direct cost savings: if each customer demands their own virtual machine, the specs of that virtual machine can be minimal, resulting in clearly lower operating costs. For instance, an IoT system running on Java Tomcat server takes about 1.5 gigs of memory to run smoothly. You can have over 100 Asema IoT Central installations running within the same memory space, with equivalent functionality.

Small and efficient does not mean less powerful. Integral to the design of the software is the idea of networked entities that can flexibly connect to each other to create a grid of nodes that perform distributed tasks in the system. While this not only allows for better scalability, it also offers a solution to the common problem of connected business applications, namely who owns the data and where data should be located. As there is no requirement for a central cloud to store data, access to data can be set by location and then shared with access rights either temporarily or permanently. Chinese walls can be established for security simply by giving each client their own instance of the Asema IoT Central in their own sandboxed environment, removing the possibility that the data of various clients could somehow be mixed up.

Asema IoT Central integrates into one solution all components needed to very easily set up a data logging and visualization environment. It not only has the required connections to databases and visualization libraries but even embeds a full blown web browser within itself. This integration gives unparallelled control of the visualization logic, including tweaking the visualization engine itself. This allows for integration of old and new visuals, e.g. an existing web application, as layers and objects. For instance one could take an existing corporate intranet site and overlay measurement data on top of it to create new visuals with absolutely no changes to the old intranet site.

Significant effort has been put into the easy deployment of the system and the applications it runs. Asema IoT Central features its own Screenlet Store, an equivalent of an app store that allows distributing IoT applications easily online. Apps can be shared between two deployments, a group of software installations or the whole user community. Automatic setup and configuration a new instance is easy: just run the setup program and type in the password for the deployment group. Network connections, security settings and applications will be set up automatically.

As an IoT central component, Asema IoT Central embeds into it support for the latest database and networking technologies. It connects to both traditional relational databases and modern NoSQL databases. It can act as both a client and a server to sensors, actuators and cloud platforms, either over industry standard network protocols such as HTTP, MQTT and CoAP or directly with a local wireless or wired connection using WiFi, Bluetooth and Bluetooth Smart.

Chapter 2. Architectural models

IoT solutions are nowadays available with at least six distingushable deployment models

  1. Platform/Software as a Service (PaaS/SaaS)
  2. Platform as a Service with Edge computing
  3. Private Cloud
  4. Private Cloud with Edge computing
  5. Local installations
  6. Grid

2.1. Platform as a Service (PaaS) and Software as a Service (SaaS)

As the name implies, in PaaS the customer acquires the IoT capabilities as a service. Usually this includes not only the application software (pure SaaS) but also the infrastructure including servers, network connections, and even the sensors and actuators. Usually the pricing of such arrangements is based on some usage volume: hours of use, megabytes of data, number of sensors per some time period. Computing capacity is bought flexibly and once the contractual period ends, the service is simply closed.

Because PaaS is based on some central computing cloud that the service provider just rents out, capacity is shared. Various virtualization technologies can be used to ensure guaranteed capacity and performance even in cases where other users cause a high load. Virtualization also keeps the data of each user separate, although because there is no actual physical separation, a theoretical possibility to gain illegal access to data over a virtual barrier exists. Further, there usually is little possibility to control where exactly and under what jurisdiction the data is stored. Due to these concerns, some security policies therefore explicitly rule out the use of PaaS.

PaaS is usually easy and fast to start with and has the lowest upfront payments of the available alternatives. It is common in applications where simple sensoring is the only feature and the sensors themselves are relatively dumb and inexpensive. Typically in such applications

  • the application does not require high security i.e. there is no need for a private or sandboxed environment
  • the manufacturing and installation cost of sensors is low and can be discarded easily; or
  • the sensors are already installed or embedded as integral parts into some equipment such as lifts, cranes, trucks, etc.

2.2. Platform as a Service with Edge

PaaS + Edge computing enhances the PaaS model by acknowledging that everything cannot be done centrally in a cloud. Some local logic is needed due to security, reliability or management reasons. Therefore the equipment at premises is "smart" and can in cases work also autonomously offline. Some more or less advanced software is therefore installed into edge devices which may be full scale servers or lower grade gateways or other embedded computers. This software then syncs with the main cloud, receiving logic rules and relaying data that may be locally stored at the edge.

A PaaS + Edge setup is typical in situations where

  • fast response time is needed at location (e.g. intelligent vehicles) or
  • reliability of control or data collection must be ensured in case of network connection errors
  • each location has customized user preferences or privacy concerns (e.g. home automation)

2.3. Private Cloud

Private Cloud is much like PaaS, but targeted towards clients who want their own, private environment i.e. their own private instance of the whole system. Technically the core software is very much the same but runs without the virtualization and quality of service technologies needed in shared environments. Private Clouds are usually applied in situations where there are questions about the ownership of either hardware or data. A private instance is usually also needed when the solution that is sought is very customized and cannot be implemented without changes that would require changes in the basic interfaces of the underlying software.

A Private Cloud would therefore be deployed when

  • the cost of sensors is relatively high or the sensors are very customized and the user organization does not want to risk a supplier lock-in on the server side; instead the preferred option is an instance of their own which can be used continuously even in case something goes wrong with the supplier
  • the application concerns private data that needs to be heavily secured and run in a private environment
  • the user organization has a blanket policy of not allowing any critical services on shared infrastructure; this is relatively common for many government organizations
  • the customer has a policy of running all their software at certain data centers and do not allow deviations from this due to cost or legal reasons.

2.4. Private Cloud with Edge

Edge computing with a private cloud is again an extension to the basic cloud model. Typically this model is a result of the need to run control and automation in addition to data collection. This architecture is something you'd most likely be deploying in confined areas with intelligent machinery, e.g. logistics centers such as large warehouses, airports, or seaports.

2.5. Local applications

Purely local applications is a domain where there is a need for IoT-like functionality but remote connectivity is not the main concern. Typical application areas are those with very high security requirements (e.g. military), experimental operations such as development labs, or modernizations of existing management and monitoring applications. Similar needs can be also found this at for instance modernization projects of factories and mills where the driver for the project is the end-of-life of previous systems.

2.6. Grid

Grid is a model where the underlying philosophy is that an IoT system as a part of a larger ecosystem of interconnections rather than just a single solution. There are several reasons for this. The most obvious one is that the system actually is a part of something larger. This is typical for instance in the energy sector: everything is connected to the same electric grid. Especially with larger loads, you cannot just power-up something without first considering its impact on network balance as a whole. Otherwise a blackout may occur.

A second, a much more common reason is the realization many IoT projects find themselves in: the system only provides value if you can actually manipulate, analyze and cross-correlate the data you collect. So you need domain specific data science knowledge. Data science for big data on the other hand is a rare commodity. Not only does it require high education in mathematical methods, the combination of both mathematics skill and domain knowledge is required. And that is usually something found only in specialist organizations. To solve the domain knowledge problem, one would need to open the system data for better outsourcing in a way suitable for scientific computing. This is where grid and API technologies come along.

In a grid system various installations act as peers to each other and synchronize data. Logic can be located in many locations: close to the action for fast response, close to the analysis for advanced knowledge. In a way everything is "edge" and everything is "central" at the same time. To make this work technically, usually there is some central directory that acts as a "phonebook" for the parties so that they know where each of them is and what type of data, logic, and controls they have access to.

2.7. Deploying Asema IoT Central in various architectures

One of the key strengths of Asema IoT Central is the versatility of the software in adapting to the various installation needs. Due to modern database support and integrated servers, it can run as well on a cloud as it can in private servers. It automatically forms grids with the native VPN connections and sharing APIs. The software is available in ready-made builds for all major operating systems and has been tested in operation on a range of virtualization technologies, including VMWare, VirtualBox, Microsoft Azure and Amazon EC2.

On an installation for single organization or application, either to a virtual machine or dedicated hardware, Asema IoT Central is deployed like any application software. After running the installer, the system is ready to be started. At first startup, the system loads with default settings which can then be changed using the browse-based admin interface.

In a shared PaaS installation, it is recommended to start one instance of Asema IoT Central for each user. Due to the very small memory footprint of the application instance and easy configuration, this requires only limited amount of added server capacity and offers the securest option with easiest administration. The database backend would usually be shared, with dedicated tablespaces and schemas for each user. All port settings and database connectivity settings of Asema IoT Central are collected into one text file that can be easily generated at the enrollment of a new client or on demand at each startup. This way multiple instances can run at the same time without conflict.

The main event loop of Asema IoT Central is based on epoll/select and is visible as one distinct process that uses one thread. This makes it easy to monitor resource use and limit it as necessary. In a shared installation the application processes should run behing a NATted firewall and a network proxy. Traffic limits to the application instances should be monitored with the tools in these dedicated components.

In local and private installations the procedure is equally easy: simply run the installer. For setting up edge gateways, Asema IoT Central has its own management functionality that allows adding edge gateways based on their IP numbers (if public IPs are available) or VPN addresses (in case the edge gateways are not behind a public IP). The necessary VPN software is installed by default in all components and is centrally managed for easy deployment.

For grid setups, Asema IoT Central supports the concept of groups and sharing through the Smart API. Traffic between devices in the same group is automatically routed and VPN connections are used in cases where a group member is behind a firewall. The Smart API helps in establishing the roles of each party in the grid. Members of the grid announce their existence and their API availability through the central directory, which can then be used by other parties to seek group members. Smart API also handles authentication, using the industry standard OAuth2 protocol, ensuring that access between parties of the grid is always authorized properly.

Chapter 3. Asema IoT Central versions for deployment

While the architecture of Asema IoT Central fits many use cases natively, one size does not always fit all purposes. This is especially true in limited environments such as embedded devices that have their own peculiarities and require specific cross-compiled versions to run. Consequently, Asema IoT software is available in three flavors. All contain the object centric, event driven core architecture which makes them easy to attach together into a large scale solution.

  • Asema IoT Central. A full fledged IoT server and client application that includes business logic, local and remote user interfaces server grade database support, analytics interfaces, server components for remote management and client interfaces for system integration. This is the software version to be run on clouds, for data collection, for data sharing and for system management. Runs on Windows (7, 10, various versions of Windows server), Linux (pretty much all distros) and Mac OS.
  • Asema IoT Dashboard. A user interface oriented component, primarily for mobile devices. Does not have database, business logic or server support but has a full event driven, automatically syncronizing user interface with a support for fully customizable IoT apps. This software is the choice for making mobile interfaces to the solution. Runs on Android and iOS.
  • Asema IoT Edge. A stripped down server for edge logic. Has a business rule engine and light database support as well as server components for system integration but only a light user interface and no data analytics support. This is a squuezed down version that packs into a very small memory footprint and can be installed into embedded environments. Compatible with embedded Linux distros such as Debian and can be cross-compiled to ARM architecture.

Because the different versions come from the same code base and contain the same core components, it is easy to mix and match them for a full solution. Designing an overall architecture therefore consists of answering a few straightworward questions

  1. Is there one or multiple locations where data is centrally stored and analyzed? This determines the number of Asema IoT Central instances.
  2. Does the application require or favor a native mobile app? If yes, add Asema IoT Dashboard to the mix.
  3. Is there equipment in the field that would benefit from local logic and offline operation? If so, install Asema IoT Edge on those

Due to the common architecture, applications designed for one software version also works in others. There for instance is no need to design a separate "mobile" app or have a different code base for Andrond devices and for Apple devices. If an app (see the chapter on Screenlets later on) has been coded for a Windows desktop, it will run equally well, and with no platform specific modifications, on a Linux PC, an Android tablet, and on an iPhone.

Chapter 4. Core software architecture

At its core, Asema IoT Central is an event driven object manipulation platform. That sounds fancy so let's dig a bit deeper on what that actually means.

4.1. Object caching and event dispatching

At the heart of the system is the application core which runs a lazy-fetching asymmetric object cache. Now that is a mouthful, too. But the basic principle is simple: keep in memory various connected objects in a way that saves resources even in situations where the system may be connected to thousands of individual objects. Lazy fetching means that the system tries to minimize loading of object data until the moment it is actually needed. This is important as the sources of those objects may not be in the core of each particular instance of the software but may be connected from gateways and other instances of the IoT Central. This object sharing makes data distribution possible. So initially the cache only has minimal info of the object, namely just the GID, name and type. When some application logic actually needs it, the rest of the data is loaded.

The loading of objects takes place asynchronously. This way the network connections always work at full speed and may download data in parallel; one slow connection does not slow down the others. Objects are recognized over the network with a Global Identifier (GID). GID's are generated in a cryptographically unique method, ensuring that the possibility of two object instances having the same identifier is non-existent. Proper randomizing is use to generate ID's that are unique between two or more systems even if there has been no communication between them when the objects were created.

The application core runs the main event loop of the application. This event loop distributes signals of events between sources and sinks, causing logic to take place in the application. Essentially every change in objects triggers an event. The most important events for programmers are property change events. Let's say that we have an object that represents a colored lamp. It has two properties: state (ON/OFF) and color. Whenever either of the properties changes value, an event is set. Various system components automatically listen to these events and customized application logic may be included as additional listeners. So for instance when the state changes, the database logger receives the event and checks whether the value should be stored to the database. Similarly the external APIs get triggered and see whether a notification should be sent forward. The UI wakes up and sees if some user interface component should be changed. The rule engine starts running business logic if some is bound to that event. And so forth.

When two Asema IoT Central instances or instances of Asema IoT Dashboard or Asema IoT Edge are linked, the caches and event dispatchers are linked together. Network interfaces make sure that events in one instance are replicated in the event dispatchers of other instances (subject to security restrictions of course). Because the event dispatcher sits at the core of the software, all applications and logic at the synchornized instance also see the changes, making them react to the changes efficiently and transparently to the applications they run.

4.2. Object types and interfaces

There are two basic types of objects in the Asema IoT Central core: active and passive.

4.2.1. Active objects

An active object makes the system behave on its behalf like a network client (and usually in the background actually runs some client software). This is why in the user interface of Asema IoT Central these are defined as "client objects". As the name implies, the object is the active party in data exchange. It activates due to some trigger such as a timer, users action or an event. When activated, the object will poll its values from wherever it has been instructed to connect to.

4.2.2. Passive objects

A passive object is something similar to a network server (and in some cases is connected to the server processes of the IoT Central). The object does not actively connect anywhere but instead passively listens to something called a feed. This is why in the user interface of Asema IoT Central these are defined as "feed objects". The source of the feed is usually some network API that external parties connect to in order to send data to the Asema IoT Central. Each feed has an identifier, when the identifier matches the object, it reads the data, parses it, and sets its values.

4.2.3. Other object types

There are two other object types that do not neatly fit these two categories. These objects are database objects and hardware objects. As one would deduct from the names, the former get their values from a database and the latter from some hardware interface. Whether the connection is active or passive depends on the database or hardware in case. Databases usually require a query, making the objects active, but some databases, most notably Postgresql also support triggers that can wake up the database driver when new data is inserted into the database.

To avoid the confusion: all objects can write their data to a database. But the database objects can get their values from a database (and possibly write them to some other database).

Database objects are handy in for instance situations where there is an external data analysis algorithm running on the database data. Those results can be written to some database table every time an analysis round finishes. The database object reads those values and provides a visualization for them.

4.2.4. Interfaces

All objects communicate to the external world through some interface. Interfaces are the route of data in and out of the Asema IoT Central. So a hardware object would use an interface that offers connectivity to the particular hardware while a client object would use an interface for the appropriate network protocol.

Interfaces embed the functionality of three concepts

  1. Driver
  2. Serializer
  3. Parser

Drivers do the actual protocol level connection to the target of the interface. The driver is the technology specific part of the connection. So a database interface to a MongoDB database would use the MongoDB driver and a serial connection interface would use a serial driver. As many of the common drivers are already embedded in the Asema IoT Central, drivers are usually something that does not require more work than just selecting the appropriate driver. But the more exotic the system to connect to, the higher the probability of having to add a driver for it.

Serializers handle outgoing data. They take the properties of the object and mold those to some message the recipient understands. Serializers are configured using a schema which is a JSON document that describes how the serializer should work.

Finally parsers handle incoming data. Just like serializers, parsers are configured using a JSON format schema. The parser takes the property values from incoming data and writes them to the object.

So essentially creating and configuring an object into the Asema IoT Central involves selecting the object type and the protocol/driver and then setting up the schema(s) for serializer and parser.

Chapter 5. Networking and VPNs

Asema IoT Central has been designed for connectivity and naturally includes technologies for establishing connections between various entities. Central to the connectivity is the CloudRoute, an embedded VPN solution for easy connections between locations. CloudRoute is a reverse SSL tunnel. This means that it uses the industry standard TLS security for connectivity but can operate birectionally, allowing the SSL clients to passively listen to and receive data in addition to being just the active connection establishment party.

CloudRoute uses various methods to securely open connections from places like corporate nets which tend to be difficult to connect to due to strict policies. Each entity is assigned communication keys and a unique CloudRoute address. Only the parties in the same VPN group are aware of these and can do the communication.

Once connected, the Asema IoT Central entities automatically sync, making it possible to do the physical connections to sensors in distributed, autonomous installations and then collect all of them under one management interface. The connections can be entirely abstracted and hidden from the user interface code: the interface simply manages the object, it does not know its origin. CloudRoute will forward the traffic to the recipient transparently based on the GID of the object.

Chapter 6. User interfaces

In user interfaces, Asema IoT Central offers a "code once, deploy anywhere" philosophy. A native interface that works on a Windows PC will work as an Android or iPhone application without modifications. This is done by laying out the interfaces with a descriptive user interface modeling language called QML and coding the logic with Javascript. They run in the host machine inside the Asema IoT software (Central or Dashboard).

Asema IoT Central offers two user interfaces: a native application interface and a browser interface. The browser interface can further be split into two: the admin interface and the customizable solution specific interface.

6.1. Screenlets

The native interface uses a technology called screenlets, graphical apps that offer views into the system. Screenlets are described using QML and embed the logic of the application in JavaScript. In this way they are very much like Asynchroinous JavaScript (AJAX) applications but have improved support for native features such as 3D acceleration and display scaling. Additionally, they don't suffer from the limitations browser sandboxes have. They can be extended with native code of the application itself for even more powerful access to resources, all the way down to device driver level, which makes them ideal for connectivity applications.

Instead of asynchronous network calls, the screenlets connect to the application core through contexts. There are various contexts that offer services for varied purposes. For instance the Device Context gives access to the device (computer, tablet) where the software runs on. A Gateway Context gives access to a remote gateway, etc.

In most screenlets the most important context is the Object Context, which is the route to the object cache and everything in it. The anatomy of a typical screenlet is that when the screenlet opens, it loads a set of objects it wants to visualize or control, then places those objects with various graphics onto the screen and starts reacting to the actions of the users. The objects then automatically sync with the application core. So if some property of an object is set in the UI code to some value, this change runs through the code of the object and if necessary all the way through the interface and cases some physical change in the object that is being controlled. With this method, custom control and monitoring applications can be implemented literally in minutes.

6.2. Custom web interface

Custom HTTP pages can be served from the webserver of the Asema IoT Central. A public JSON interface offers functions for object management, including object searching and fetching and setting the properties. Additionally there is a websocket server that can be used to tap into the event system. The interface will then receive notifications of the events and can react to them in real time.

Asema IoT Central includes a compatibility library that offers the same context and event signaling services to HTML5 as is available for QML applications. With the library, interfacing with the backend is easy and structurally identical as in the native UI. It hides the details of necessary network communication and listening to notifications and exposes these in a uniform object and event interface. For control and monitoring this resuts in fast and straightforward implementation.

Apart from the interfaces and libraries that help in communicating with the backend, the Asema IoT Central is "just" a plain HTTP server. It can therefore accomodate any code, javascript libraries, CSS, or markup you'd put into any other web interface. In this respect there is no limit to what the HTML UI may look like or what it may do. For organizing the interface the Asema IoT central offers a powerful templating engine, content authoring tools for users, and methods to implement server side logic and request processing in a similar way you'd find in for example a Java application server.

6.3. Admin interface

The Asema IoT Central admin interface is an HTML5/AJAX application that loads from the HTTP server of the IoT central and then communicates with the system using a JSON interface. The functionality of the admin interface is closed and cannot be modified but some of the components in the admin interface are available also for creating custom admin interfaces.

Chapter 7. APIs

To integrate the Asema IoT Central further into other systems, the IoT Central offers two key APIs

  1. The JSON RPC API
  2. The Smart API

7.1. JSON RPC API

The JSON RPC API is an API format familiar from a majority of modern network services. The API is called with a standard JSON RPC call, comprising an ID, a method name and paramters. Methods include searching, fetching and controlling the objects in the system.

The API uses objects and their GIDs as the base concepts. So in practice an API instance user would run a search to get a list of the GIDs of objects and then run a second search to address an object by including its GID in the subsequent requests. Below is a basic JSON call to fetch all objects in the system.

{
 "id": 1,
 "params": None, 
 "method": "get_objects"
}
   

The response to the request is a JSON structure that lists the objects in the system with their names, types and GIDs. The caller would then pick from that list those objects that are relevant. In a more realistic case though the call would not be "get_objects" bu rather "filter_objects" which allows setting various search filters that match the desired objects.

In case the next step is to control an object, a JSON command would be sent to it. Let's assume it is a switch command to set an appliance into ON state. This would look as follows:

{
 "id": 2,
 "method": "turn_appliance_by_gid",
 "params": ["<some GID from the list>", true]
}
   

The corresponding OFF command would set the last parameter to false.

7.2. Smart API

The Smart API is an API for linked data. It is a comprehensive set of definitions and functionalities for object management in a smarter way. Usually the recommended approach is to use the JSON RPC API for applications where the number of connected systems is limited and known beforehand, such as the integration of internal systems of an organization. The Smart API on the other hand has been designed for proper data exchange between organizations and for open data. It is more carefully designed than the JSON API and the data definitions are much more comprehensive. This removes a lot of the ambiguity in the data and not only offers more features but also improved reliability and maintainability.

So let's illustrate the design, rationale an use of the Smart API a bit to understand why it is used.

Here is one typical pure JSON style design. This could be a payload, that as a result to a call

{
 "weight": 3,
 "height": 4,
 "delta": 0.5
}

What makes the design problematic is that without some supplementary documentation, it is hard to tell what this data is all about. Height of what? Weight of what? Is this a bird, a plane? A man wearing red underwear on top of tight blue pants? What is that delta applied to, is it the difference to weight or height? Compared to what? What is the measure of height? 4 something; centimeters, meters, kilometers?

Usually in this kind of case, the author of the API releases some API documentation which explains what the content actually means. Here's an improvement, the API Doc.

Weight. The weight of the contents of the box, excluding the box itself, expressed in kilograms.

Height. The height of the box, in centimeters.

Delta. The maximum deviation of the height of the box, expressed in centimeters.

With the documentation, the situation is naturally is much better, now we understand what those numbers are. But there still are several problems in this API payload.

  • First, someone needs to find the API document, read it and understand it. This requires time and manual work.
  • Second, because the definitions are outside of the payload in an external documentation, the spec is rigid and changing the API is difficult. What if in some cases we would actually like to express the height in millimeters. This is not possible without releasing a new version of the API. Even then mixing different quantities, i.e. sometimes give the values in centimeters sometimes in millimeters, would not be possible.
  • Third, the spec is separate from data. While admittedly this makes the payload small in size, the importance of such considerations is diminishing due to high speed connections. Of increasing importance starts to be the storage and later use of that data. The assumption behind payload formats is that the recipient will parse the data and further process it immediately. But in many data mining applications this may not be the case. In them the data should be stored in document databases such as MongoDb in their original form to avoid losing any information that might become valuable in the future. But in this case also the documentation would need to be stored, otherwise no-one will understand the data ten years from now.

Let's write the same thing in Smart API style. It adds important linked identifiers into the data. This data is now not just JSON, it is JSON-LD (JSON for Linked Data), one format of RDF.

{
 "@context": {
  "smart": "http://smart-api.org/ontology/1.0/",
  "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
  "nasa": "http://data.nasa.gov/qudt/owl/unit#",
  "qudt": "http://www.qudt.org/qudt/owl/1.0.0/quantity.owl",
  "xsd": "http://www.w3.org/2001/XMLSchema#"
 },
 
 "smart:weight": {
  "nasa:unit": "qudt:kilogram",
  "rdf:value": 3^^xsd::int
 },
 "smart:height: {
  "nasa:unit": "qudt:centimeter",
  "rdf:value": 4^^xsd::float,
  "smart:maxDeviation": 0.5^^xsd::float
 }
}
    

See the difference? The data now specifically defines what it is. The structure properly identifies the numbers as weight and height and assigns the maximum deviation into height. What is more, units are properly given so that computers can recognize them and even do automatic conversion on the fly. The data also starts with links to what is called the context. This contains links to locations that have the actual written definition of that data. There is no need for an API doc, the data can explain itself. You can actually give the Smart API SDK the command "explain" and it will output a human readable description of what the data is about.

Authoring systems that use the Smart API naturally takes more work because the design is more elaborate and there are more details to transfer. To help in this, Asema offers a free Smart API SDK in all major programming languages. The SDK creates the messages on the fly and the required amount of code in languages like Java is nearly identitical between traditional JSON and Smart API JSON-LD.

Chapter 8. Customizing and building application logic

While much of the logic of basic IoT functions, including business rules, timers, and controls, can be simply configured into the Asema IoT Central by using the admin interface, real applications often need custom programming to achieve the eventual use case in full detail. Asema IoT Central offers multiple different tools for achieving this, each having their pros and cons. The eventual weapon of choice (or their combination) depends on the application.

8.1. Client side scripting

Client side scripting basically means writing application logic in JavaScript. This option is available for both local Screenlet UI's and of course for HTML5 applications. Client side scripting offers many benefits, for instance

  • A programming language commonly known by both user interface and backend programmers
  • An easy way to distribute the logic together with the user interface through the Screenlet Store
  • Load reduction from the server as most processing is done at client devices
  • Reduced network traffic.

However, there are downsides to this approach, too. Not all analysis can be done at the client, especially if it concerns large amounts of data. Downloading everything for local number crunching just to discard most of it just plain dumb. And some of the analysis features such as advanced calculation libraries are simply not available or not powerful enough. Further, in case the application concerns proprietary code, that will be hard to protect from copying and analysis.

8.2. Server side scripting

Asema IoT Central also offers the possibility to run JavaScript logic within the server side JavaScript engine. This way it is possible to program request processors just like in an application server, but instead of Java the language is JavaScript. Each code snippet runs as its own instance that can receive request data and return response data.

If you've ever programmed with server side scripting solutions like node.js, you should feel at home with Asema IoT Central's approach to request processing. Like node.js, the IoT Central is based on signals and an event loop. This is why the programming style is the same and the syntax mimics that of node.js, making transition very easy. In addition to the events, Asema IoT Central of course offers the core object and property model, which makes handling connected objects from the server side scripts convenient.

Server side scripting is great for protecting code or for offering the same logic for all users. However, it does then also consume the resources of the server to run.

8.3. Native plugins

Native plugins are a bit like "turbo-boosted" server side scripts. Instead of JavaScript, plugins are programmed in C++. They are compiled into dynamic libraries (dll on Windows, .so on Linux and Mac OS) and loaded into the system at runtime. Binary format libraries offer even further protection to the intellectual property of the code and runs much more efficiently. Consequently, they can be used to easily extend the features of embedded systems, too.

8.4. Shared database

One option for implemeting application logic is to have algorithms running as autonomous applications that periodically run through the data in a database, do some number crunching and write the results back to the database. The database objects of Asema IoT Central are designed to interact with such logic. They can automatically "wake up" when new data arrives in the database and will change their properties accordingly. Scripts and rules that monitor those properties will then be triggered and change user interfaces and other data.

8.5. Forwarded logic calls

Sometimes it is desirable to run application logic entirely in some other server. For instance the main application logic could run in a Java application server while Asema IoT Central only handles the connectivity. When an AJAX application makes a call, Asema IoT Central can forward such requests at the backend, request the result from the other server and then return it to the user interface. The users simply see one, uniform and coherent interface. This approach is beneficial when

  • An existing application is already implemented in some other platform and there is no reason to port it to a new one
  • Java, C# or some other server language is known by the software engineers and they prefer to continue using it.

8.6. Proxied requests

In addition to requesting just an AJAX call, Asema IoT Central can act as a proxy for a full HTTP request-response cycle. In this case the target system receives the full request will all header information. In this manner it can render full pages of an HTML5 interface, not just the logic and data part.

8.7. Smart API

The Smart API offers a modern way to connect two or more compatible IoT solutions together and therefore works also in distributing the application logic between servers. Conceptually, Smart API calls work much in the same way as the forwarded logic calls. However, the Smart API calls offer further standards compliance, the possibility to dynamically interpret the call context and forward it to the best recipient, enhanced confidentiality and access control, and the possibility to track the financial value of the data transmissions.

Further information and support

Asema's website at www.asema.com gives you more information about Asema's products and their technology. Visit the support site for latest products announcements, compatibility information and latest online versions of manuals.