Database

In the reference design and implementation, we will be using AWS DynamoDB. However, alternative NoSQL databases such as MongoDB may be used. It is possible to use a Relational Database (RDBMS) as well, although that can be restrictive if variable structure data is to be managed (such as sensor data).

The following terms are used across databases.

While DynamoDB and MongoDB are both NoSQL databases, MongoDB uses JSON while DynamoDB used a JSON-like structure.

DynamoDB supports two JSON formats:

• DynamoDB JSON format which maintains the data type along with each item attribute.
• Regular JSON which does not support data types. We will be using regular JSON in this implementation.

When using the DynamoDB database from an application it provides APIs that allow you to work with JavaScript objects (which are similar to JSON in structure).

Data Design

The data in the solution will be divided into multiple categories:

• Master Data: This is the configuration data or entity data that is static/constant through the operations. It will be used for validation of input data by the microservice (authentication of microcontroller and sensor ids, filtering outlier data) before writing to the Smart Contract. This will be stored only in the NoSQL Database and not in the Smart Contract.

• Operational / Transactional Data: This is the data that is received from sensors as input or calculated as part of the process. This will be used for all Smart Contract penalty and payment calculations.

This is further divided into two categories based on storage and purpose:

• Analytics Data: This is data stored in the NoSQL database and is used for analytics purposes.

• Blockchain/Smart Contract Data: This is data stored in the Blockchain and Smart Contract and is used for decision making and execution of actions such as payments.

Microcontrollers and Data Management

Since there is a physical computing component which involves microcontrollers that are pre-programmed and sensors that are physically attached to the microcontroller, the data must be managed in a way that minimizes microcontroller and sensor level changes.

To support this, the physical attachment of sensors to a microcontroller will be maintained in the database and assumed to be fixed. Thus, when a microcontroller is selected by id, the sensors attached to it can be determined from the mapping.

Microcontrollers will be mapped to a vehicle in the database. This will allow a microcontroller to be moved across vehicles without needing any re-programming, only the mapping in the database will have to be updated.

Tables

The tables and data required for the solution are listed below. All data can be pre-populated manually, except for the OperationalData table which will be populated with data from the sensors using Lambda functions.