In this section, examples of data models related to the example/solution reported above for monitoring Vehicles and Drivers are shown. Entity Models (IoT Device Models) for Drivers, driverHealthiness, Vehicle, and VehicleEvent, etc., are described.

Each model is represented as a table as with the following schemas.
Typical Entity Model (IOT Device Model) for User Profile
According to the above description, for each Entity Model that would be used to create Entity Instances with Entity Messages changing over time the dateObserved variable has to be defined. The dateObserved is the date and time at which the user profile is updated, not the timestamp of its insertion, but the timestamp of acquired data on the field. In the case of User profile, the evolving over time is particularly useful for versioning the user profile data and for tracking the general user profile state evolution. For example, to state that a driver is active or nonactive, etc., to save the time in which the driver changes the car, to save the time and data related to driver conditions and locations, to mark the timestamp and maintenance info of an equipment, etc.

Entity Model / IoT Device Model: Driver Nature:……………. Subnature: ………………… Lat,lon: Default (they do not need to be  specified in the variables, they are provided by default, but values have to be imposed at the instantiation of the device from model), they are float Device/Entity in Mobility: No (the variable does not need to be specified, while the value has to be set to state if the Lat, Lon are going to change, moving the device or not)
Value_name	Value Type	Value Unit	Data Type
dateObserved	Timestamp	Timestamp in ms	String
Identifier (nickname for ex.)	ID	text	String
name	entity	text	String
surname	entity	text	String
age	age	number	Integer
sex	status	some coded status	String
language	entity	text	String
email	entity	text	String
phone	entity	text	String
address	entity	text	String
locality	entity	text	String
city	entity	text	String
nationality	entity	text	String
civicNmber	entity	text	String
dateofBorn	DateTime	Timestamp in ms	String
gender	status	some coded status	String
driverHelthinessID	Identifier	ServiceURI	String
driverEventID	Identifier	ServiceURI	String
driverAnalysisID	Identifier	ServiceURI	String
VechicleID	Identifier	ServiceURI	String

 

Entity Model / IoT Device Model: driverHelthiness Nature:……………. Subnature: ………………… Lat,lon: ……….. Device/Entity in Mobility: ………..
Value_name	Value Type	Value Unit	Data Type
dateObserved	Timestamp	Timestamp in ms	String
kind
levelAttentionFactor1
levelAttentionFactor2
driverID	Identifier	ServiceURI	String

 

Entity Model / IoT Device Model: Vehicle Nature:……………. Subnature: ………………… Lat,lon: ……….. Device / Entity in Mobility: ………..
Value_name	Value Type	Value Unit	Data Type
dateObserved	Timestamp	Timestamp in ms	String
producer	entity	text	String
model	entity	text	String
plate	entity	text	String
companyID	entity	text	String
velocity	velocity	km/h	float
acceleration	acceleration	m/s2	float
Status	status	some coded status	String
energyLevel	energy level	percentage	Float
kmTotal	distance	km	Float
thankLevel	energy level	percentage	Float
vehicleEventID	Identifier	ServiceURI	String
driverID	Identifier	ServiceURI	String

 

Entity Model / IoT Device Model: VehicleEvent Nature:……………. Subnature: ………………… Lat,lon: ……….. Device / Entity in Mobility: ………..
Value_name	Value Type	Value Unit	Data Type
dateObserved	Timestamp	Timestamp in ms	String
eventID	ID	text	String
eventKind	status	some coded status	String
status	status	some coded status	String
vehicleID	Identifier	ServiceURI	String

 

For example, at level of their relationships we have the example of the next figure.

In the next figure, an example of the above provided Entity Models:

• We can assume that each User playing the role of Driver (or operator) would be registered on Snap4City as Manager role into some organization indicated by the platform manager.
  
  • Once registered the User is going to provide its own/preferred Nikname (also email, that is the username) and password to access at the platform on web and mobile App.
  • The Mobile App and Web app should be compliant with the Authentication model described in the following.
• The doctor/operator would enter the information of each User involved into the experiments. Thus, the operator will perform the registration of the Device / Entity representing the User and connect the Entity with the NikName (user name on platform). To this end a dedicated Dashboard for registration is produced that will provide forms to be filled and the Proc.Logic / IoT App to register a Device for the User by using the device from model node in node-red.
• The Dashboard for registration should be designed to request via a form the User’s personal data according to the above user profile Entity Model, and thus including the platform Nickname into the Proc.Logic / IoT App.
• To collect data from a dashboard it is possible to use at least two solutions from Proc.Logic / IoT App:
  • Use FORM node of dashboard widgets: https://www.snap4city.org/714
  • Produce a form on HTML page, and export into some External Content. https://www.snap4city.org/618 
• The Dashboard for registration will have a Processing Logic (IoT App) receiving this information and:
  
  • registering Entity Instance from Entity Models:
    • Driver1 from Driver Model
    • Driver1Healthiness from DriverHealthiness Model
    • Driver1Event from DriverEvent Model
    • Driver1Analysis from DriverAnalysis Model
  • write into the Driver1 Entity Instance the user nickname to establish a link.
  • write the first messages for devices: Drive1, Driver1Healthiness, Driver1Event, Driver1Analysis to establish the reciprocal relationships via SURI.
  • delegate in reading to the User Nikname the devices: Driver1, Driver1Healthiness, Driver1Event, Driver1Analysis.
  • perform delegations in reading to enable doctors, analysts, etc.  it can be possible to have a group of users (group of doctors, group of operators, group of analysts), and thus to make those delegation to the group. All platform user joining the group will be automatically authorized.
• The User can access to the Entity Instances in reading and thus can read data from its mobile app once authenticated.
• Conceptually, the data and the results of the analysis will be produced by some operator/doctor and thus not from the User.
• If the User or some its device when authenticated, it has to send data to some device, and thus it has to be the owner or to be delegated in writing for that device. The User may need to produce data coming from some device such as mobile phone tracking its position, etc. In this case, he has to be the owner of the device, or to be delegated in writing (READ_WRITE), according to the GDPR he should be capable also to cancel or overwrite the data, etc. A workaround could be to receive the data on platform permitting at the user to write the device. Periodically copy those data in a shadow device owned by the organization which is guarantee the long terms safe of the data.
  
  • May be with some blockchain (work is in progress on the blockchain feature on Snap4City).

Figure: Example of relationships among Entity Models (IoT Device Models), Entity Instances (Devices) produced from them, and Entity Messages (device messages) posted for Entity Instances (devices). In the picture, it has been added an entity for modeling the Drive Section (DrvSect1). It describes the section by means of its start and end of the section and the vehicle used (other info can be added as well, such as root, motivations, delivering info, etc.). In addition, the events can be included into the drive section or outside. Moreover, also the operator which may manage a set of possible Drivers has been added. For example, by recording any start and end of established relationship from the Manager and each driver, etc.

Please note that: since the names of the Entity Instanced involved are all declined with the same ServiceURI prefix, the Mobile App needs only to know the Driver SURI to know the SURI of the connected Entity Instances. On the other hand, a more formal approach would be to save the SURI of the connected Entities directly into the Driver Entity Instance by using a Entity Message, in fact some SURI may change over time, such the car which is going to change driver every day, for example.

See section IV.C.1.d to see how to maintain aligned different devices with a sort of Trigger / Sync flow implemented in Proc.Logic.

---

---