Geo-IoT references in Smart Cities

Geo-IoT references in Smart Cities

When a city wants to deploy an IoT infrastructure to support smart city services, an integrated reference model is among the first needs to manage who is sending the information, where it is located and how can I manage the device for service provision (security, updates, etc.).

In Citisim any IoT device has an EntityID. EntityID is an 8 bytes number with the first two bytes identifies the organization code. The rest of the ID is free to be organized by the organization according to its needs. For example, in the Citisim project, the University of Castilla-La Mancha will use the next two bytes to identify a specific area ID (e.g buildings) and the next 4 bytes is a sequential number. The EntityID usually will identify a specific sensor/actuator and it should be unique. It also can be used to identify specific instances of a software service.

Every sensor/actuator has a number of static properties, usually stored in the property service. The properties associated with a specific reading (e.g position on mobile sensors) will be included in the event of the specific reading as metadata.

A device identified by an EntityID is located in a specific area or point. This area is identified by an AreaID which is an RFC 4122 compliant identifier. Some areas also have a human-readable ID, that is, a name that has a sense for a human (e.g /CP13005/CAMPUS/ITSI/ARCORESEARCHLAB). A specific area is defined by a shape (its perimeter) which is a vector of N points. The vector represents a closed perimeter (i.e Vector[0]=Vector[N]). In the case of an area which represents a single point, the shape only has one point.

In the same way, a sensor covers a specific shape. For example, we can represent a shape with the coverage of a camera.

Meanwhile, outdoor positions are easy to get with GPS coordinates, in indoor we will support two methods, the first one is to fix a reference point outside of the area (a GPS point) and to express a relative position to such point (X, Y, Z). The second one is to use Open Location Codes, an open standard created by Google (https://plus.codes/).

For an indoor global position, the area takes up a set of one or more Open Location Code plus information about the altitude.

In CitiSim, with this reference data model, the location service, the property service, and the Scone common-sense reasoning engine will answer to requests as:

  • Which camera/s cover this area/point now?
  • Which are the state/position of all energy sensors in a specific area? (in 3D)
  • Which is the next camera to monitor for a specific vehicle tracking?

Meanwhile GIS services are more focused on statistical data and services, in Citisim we have a deal with real-time geo-IoT information services. In our data format, we have mixed the sensor/actuator position, area of coverage/influence and a homogeneous IoT identification. As storage data format we are exploring indoorGML (using it also for outdoor) so we can be more easily compliant with future services/tools.

Author: Felix Villanueva, UCLM

Company: Abalia