Functional Design

The level of detail of the functional design proposed by the Ignite | IoT Methodology in this phase is typical of what would be found in a lightweight response to an RFP (Request for Proposal). This should be sufficient to start the implementation phase of a project, especially if using an agile approach in which a product backlog is groomed in order to capture and manage detailed requirements. The functional design described here is not intended to meet the more detailed requirements of a fixed-price offer, for example.

Getting Started: Use Cases and UI/HMI Mock-ups

A good first step towards creating a functional design is to establish a high-level catalog of the most important use cases (strictly speaking, the initial use-case catalog should be created as part of the original analysis, but since it is an important design artifact we have included it here). For an IoT solution, these use cases can often be identified by looking more closely at the asset lifecycle (see discussion on Connected Asset Lifecycle Management in the Introduction). Each use case definition should follow established best practices for use case design (see TBD:REF), and provide a high-level description of the stakeholders/roles and activities involved.

Alternatively, in a more process-oriented organization, a process-centric approach can be used. In this case, instead of a use case catalog, a process value chain can be created for the solution (again, most likely based on the asset lifecycle). For selected processes, it is also possible to use a process flow diagram, using ePC or BPMN, for example. However, in this case, we recommend sticking to a fairly high level, focusing on the “happy path” process flow.

Regardless of the approach taken, this work is usually carried out by the team’s business analysts, with support from the solution architect. Many business analysts and solution architects are highly structured in their thinking and like to start the functional design process using a structured approach. However, a key aspect of functional design is close interaction with end users and business stakeholders. And within this group, we often find people who are less structured in their thinking. Often, these people don’t like abstract thinking, and prefer simple visualizations, as provided by UI mock-ups, for example. Because many in this group think in terms of applications, it is important to ensure effective communication by speaking to them in these terms.

This is why Ignite | IoT  recommends creating initial mock-ups for the solution’s key User Interfaces (UIs) and Human Machine Interfaces (HMIs). These mock-ups should be lightweight and focus on the key interface identified as part of the use case or value chain analysis mentioned above. Mock-ups provide an ideal basis for discussing ideas and validating requirements with end users and business stakeholders. They can also help identify and capture the full picture in terms of important data entities, use cases, processes, events, and so on. For an IoT solution, the following mock-ups are typically relevant:

• HMI: Asset user and asset administrator interfaces (e.g. machine HMI displays, remote web interfaces, car on-board displays, etc.)
• End user self-service interfaces: User account management, personal usage statistics, etc.
• Process support interfaces: UI for call center agents, for example
• Partner interfaces: UIs for solution partners, incident management for external support providers, for example

Adding Some Structure

Most likely, the mock-up approach described above will not be very structured in the initial stages. It focuses heavily on the user point of view and sees processes, algorithms, and the like from a black box perspective.  For this reason, Ignite | IoT  recommends taking a more structured, IoT-specific design approach in parallel (again, the boundary between analysis and design is not black and white here).

Most IoT projects have developed certain theories that have become a fundamental part of their business model. For example, the people at CERN have built the Large Hadron Collider (LHC) based on physical theories that date back to Einstein and others. Or take Google and Nest: It’s quite likely that Google have made assumptions about the kind of analytics they’ll be able to run with the data gained through their acquisition of smart home technology provider Nest.

One problem with these theories is that until they have been proven, nobody knows for sure if they are right. And especially in an IoT world driven by sensor data/big data, many theories and business model assumptions will evolve over time as people learn from the data they have collected.

For many IoT projects, the creation of a digital model of the physical world based on sensor data forms the basis on which these theories and assumptions will be proven. Which is why the process of carefully designing this digital model is a key part of the solution design process. The assumptions made in the business model will have to drive the granularity of the digital model. It needs to be able to answer important questions:

• What data entities will have to be collected?
• How often?
• To what level of accuracy?

Take the example of a soccer game: if, in terms of business model, we are a betting agency, then capturing the results of each game should be sufficient. Unless we also need the information about each individual goal, i.e. who scored the goal and when. If we are the coach of a soccer team, our business model demands that we continuously optimize team performance. So in this case our digital model would be closer to a heat map that tracks the positions of each player for the duration of the game. Some teams have already started tracking the detailed movements of individual players using high-accuracy positioning systems and motion capturing technology to allow for performance improvements in individual players. When visualized in 3D, these models already look very close to the real game.

Keep in mind that the creation of a more detailed digital model can dramatically increase the cost of project implementation, data transfer, and operation. In many cases, you will be surprised at how even very simple digital models can produce powerful business models.

The next question in the design process concerns the inception points that can be used to capture data. What types of sensors can be used? Where can they be positioned? How can they be accessed remotely? What’s the best way of ensuring adequate power supply? And so on. To stay with the simple soccer example; how can you actually capture the fact that a goal was scored? Up until recently, very few soccer leagues allowed or required goal line technology. So what are your options if there is no direct way of capturing the required information? Can you deploy a microphone system in the soccer stadium to measure the applause, working on the assumption that loud applause or protest indicates a goal?

This brings us to the next phase, the “Reconstruction” phase.  We will see that the data collected from sensors doesn’t always map directly to the required digital model. In this case, we need to implement a process that takes available sensor readings, events, etc., and then uses this data to create the digital model we need in order to support our business model.

To take an admittedly artificial example, the reconstruction process for our simple soccer scenario above could combine the information about loud applause or protest with the information about which team is playing at home in order to determine the team that actually scored the goal.

To take a more realistic example of a reconstruction process, let’s look an IoT solution that uses beacons to track movements of customers in a retail store in order to make location-based shopping recommendations. In this example, the first part of the reconstruction process is to map beacon-specific information (distance, positions of beacons, etc.) to customers’ actual 3D coordinates. The next step is to map customer positions to potential areas of interest, so that the recommendation engine can do its work.

One example that takes the concept of reconstruction to the extreme – and actually inspired our use of this concept – is the CERN/LHCb case study described in Part I:

• LHCb deploys more than one million sensors to get low-level, analog data
• A highly complex, multi-tiered reconstruction process is triggered for each particle collision by combining these analog events with the 3D coordinates of each individual sensor
• The result is a three-dimensional model of the trajectories of each individual particle after the collision
• Based on this digital model of the collision, physicists can validate their physics theories about particle collisions

This example shows how important the concept of reconstruction is in the IoT world (apparently if you do it right, you can win a Nobel price). Especially for IoT solutions that rely on more complex digital models and sensor data, the Ignite | IoT Methodology recommends investing sufficient time and resources in defining the digital model and the corresponding reconstruction process.

If the solution architect is convinced that there is a good match between the digital model design and the reconstruction process, they can use this digital model as an abstraction in the next steps of the design process. As we will see, the digital model for an IoT solution can have multiple facets. At its core, we recommend creating a domain model (see below) to provide a consolidated, business data-centric, technology-independent version of the digital model. Over time, the model will need to be updated to include events, components, processes, etc. Let’s start with the domain model.

Domain Model

Domain models are neither new nor IoT-specific. However, they can be a powerful tool in helping to create a business-oriented, consolidated view of the key data entities of an IoT solution.

We recommend using very basic UML elements for the domain model, such as:

• Classes
• Attributes
• Associations
• Aggregations
• Inheritance/Specialization

A good starting point for identifying the key entities in your IoT solution are the 4 key elements from the stakeholder analysis discussed earlier:

• Assets and Devices: Identify between one and five key entities. What attributes of the assets and devices are particularly important?
• End User: Users and specializations such as asset owner, back office staff, etc.
• Enterprise: “Lease” as the key entity that defines the relationship between the asset and user, for example
• Partner: Assignment of incidents, for example

On a broad level, the domain model should focus on the key entities and their most important relationships. Knowing what to omit can sometimes be as tricky as identifying the key entities. Some advice:

• Avoid “1980s entity/relationship wallpapers” – a domain model usually has between 15 and 30 entities, no more
• Use simple UML, as described above
• Allow for a certain level of “vagueness:” this is especially important in this age of NoSQL databases and an environment like the IoT where not all data types will be known in advance

As we will see, one key advantage of the domain model is the ability to create a visual representation of the data distribution across the different solution layers. Leveraging SOA (Service-Oriented Architecture), we can map the entities from the domain model to the different components.

Asset Integration Architecture (AIA)

The Asset Integration Architecture (AIA) is an architectural approach that has been specifically developed for IoT solutions. A description of the high-level concept has already been provided in the introduction. Two main tiers are introduced here: asset and enterprise. These two tiers are integrated through an IoT Cloud (or an M2M Platform). In the asset, the local gateway and agent software allow integration with the different devices that form part of the asset. The gateway also ensures connectivity with the backend. In the backend, the IoT Cloud usually has an integrated database containing information about all of the assets that have been registered with the system. The IoT Cloud ensures that this information is synchronized with the actual data from the asset. The IoT Cloud backend typically contains very asset- and device-specific data and functionality and is integrated with backend applications to provide additional business services.

The example above shows an AIA for the eCall service. The eCall solution consists of a call center application in the backend, which integrates with the so-called PSAP (Public Safety Answering Point). The backend also contains the eCall Event Processing subsystem, which receives events from vehicles in a potential crash situation. These events are submitted from a TCU (Telematics Control Unit) in the car. The main purpose of the TCU is to act as a gateway, but it also has some limited business logic running locally, as well as an acceleration sensor which forms part of the solution. Also, the TCU integrates with the airbag via a CAN bus.

The main purpose of the AIA is to provide a canvas that can be used to present the different architectural elements of an IoT solution in a standardized way and to provide information about the distribution of the different architecture elements in the IoT solution.

Data Distribution

Now that we are familiar with the concepts of Domain Model and Asset Integration Architecture, we can combine these two concepts to address data distribution. This is a very important aspect of any IoT Solution. A naive data distribution design can lead to significant performance problems and unnecessary communication costs.

For each of the entities identified in the domain model, the task is to identify where in the AIA these entities might exist – either by design (green-field), or because they already do (brown-field). Closely related to the distribution of data is the distribution of key business rules.

An experienced solution architect will typically have a good overview of the key restrictions that apply to data and business rule distribution, such as latencies and bandwidths between the different tiers of the AIA, local storage restrictions, and processing limitations, etc. By combining these restrictions with quantity structure information from the original analysis (e.g. expected number of assets, etc.), they can create an initial proposal for the data distribution design by mapping data entities and rules to the AIA.

For example, say that a smart home solution requires an important business rule that makes a decision based on room temperature and weather forecast. In this case, the solution architect has two options:

• A (local rule): Push weather forecast data to the smart home appliance on a regular basis and run the rule locally
• B (backend rule): Send the current room temperature to the backend and run the rule in the backend each time a decision is needed

The tradeoff is clear: how much data traffic will option A generate as a result of pushing weather forecasts from the backend to the appliances versus how much traffic will option B generate as a result of pushing data from the appliances to the backend? There are a number of factors to consider here, such as the number of appliances, required update frequency and data volumes for weather forecasts, average number of rule executions per appliance, etc.

This relatively simple example and the resulting complex analysis clearly demonstrates why an efficient distribution design for data and business rules is so important to the success of an IoT solution.

SOA Landscape

Closely related to the discussion above is the topic of software componentization. Once hyped, Service-Oriented Architecture (SOA) has come through a lengthy learning curve and is now seen by many as an unsexy but necessary approach to addressing the problems associated with distributed, heterogeneous software systems.

An SOA typically has two perspectives: a technical protocol perspective (REST versus Web Services) and a functional perspective. The whole area of standardizing technical protocols for the IoT is still very dynamic, so our focus here will be on the latter, the functional perspective. As described in (TBD:REF Enterprise SOA and Enterprise BPM), the functional perspective defines the 4 key layers of an SOA that can be applied across application silos independently of the underlying technology: UI, Process Logic, Orchestration, and Basic/Data-Centric Services. The advantage of looking at a heterogeneous application landscape through an SOA perspective is that it becomes quickly transparent which application silo owns which data and which processes. This is important information, which is usually hard to come by. Also, this perspective is helpful in identifying the software components and their dependencies on a non-technical level. This can be interesting for the data and logic distribution discussion above, for example. In the later stages of the design process, the provision of technology-independent documentation for the key software components and their interfaces also becomes important. In many cases, a Wiki-based approach is preferable over a technical SOA repository because of the associated overheads.

In a distributed system with network latencies and bandwidth limitations, the design of the component interfaces must be as efficient as possible. The experience from distributed object computing (CORBA, DCOM, J2EE) has shown that complex object interaction patterns are not suitable for most distributed systems. Instead, simpler, RESTful services have been introduced. The same patterns and restrictions also apply to the design of software components in the IoT – if anything they apply more, given that aspects such as high latencies, network service disruptions, and other problems are even more of a factor due to the open nature of the IoT.

Consequently, Ignite | IoT proposes to build on existing best practices for SOA architecture design and extend these to the IoT. From an SOA point of view, the applications running on an asset are no different from any other application. Since SOA takes a technology-agnostic perspective, adding embedded applications and real-time operating systems to the already heterogeneous SOA world of Java, COBOL, and PL/1 code shouldn’t make a difference.

As can be seen in the diagram below, Ignite | IoT proposes to extend the familiar SOA map diagram (TBD:REF Enterprise SOA and Enterprise BPM) by adding a section for assets to the right and extending the UI layer to include HMI (Human Machine Interaction).

This type of SOA map can be of great value in helping to identify the key software components that need to be integrated or developed as part of the IoT solution. The SOA perspective is different from the Asset Integration Architecture (AIA) perspective described above in that the main focus of the SOA is to make the key software components and their main business functions transparent. The SOA perspective proposed here is technology-agnostic and really focuses on business functions, while an AIA takes more of a systems perspective, possibly containing references to concrete technologies used.