The Internet of Things (IoT) is the next big thing in the internet world. The writer says while the IoT has the potential to transform geoint, there is a need for the geoint community to participate in IoT development
Geoint as a discipline underpins not only defence and intelligence, but also public safety, disaster management and many other areas. Geoint is intelligence based on IMINT – imagery and information derived through interpreting imagery – and diverse types of non-imagery geospatial information. Increasingly, geoint information products are created by ‘fusing’ data of many types that are produced in a variety of ways. It is also the case that geoint provides a geospatial foundation for most of the other intelligence gathering disciplines : HUMINT (human intelligence), MASINT (measurement and signal intelligence), SIGINT (signal intelligence) etc.
The Internet of Things (IoT), which Wikipedia says, “refers to uniquely identifiable objects and their virtual representations in an internet like structure,” could be transformative for geoint and any intelligence activity that involves things whose location matters. The internet connection is critical, because the IoT depends on the ability of systems to:
- Communicate information about things and their locations
- Communicate information from things, including information about their locations
- Communicate instructions to things – to control sensors and machines
The small, fast, limited functionality information systems embedded in things may communicate with each other, as happens when tiny UAVs fly in formation, and the information systems may at the same time be communicating with powerful data, processing and communication resources in the cloud. The IoT is very much a “system of systems.”
‘Activity-based’ and ‘Event-based’ intelligence are terms that appear more and more frequently in intelligence discussions. These categories of intelligence invariably involve people and things whose locations matter. These people and things often need to be communicating location and location-related properties such as proximity and adjacency, area and volume, path and trajectory, spatial probability, signal strength, and line of sight, all of which also have a temporal dimension — speed, rate of change, history, etc.
The IoT has the potential to transform geoint, but the geoint community needs to participate in IoT development if the community is to acquire the system of systems that matches community needs.
`A system of systems depends on standards. Internet provides a channel for communication, but location communication requires standards — software interface and data encoding standards, and best practices — that meet requirements like those outlined above. Those requirements are only partially satisfied by current standards.
Building the IoT is an international project, and progress is being made in the Open Geospatial Consortium and its many partner standards development organisations. A few in the information technology world, however, fully realise how important and cost-effective participation in these organisations can be, or how beneficial such participation is for participants.
Which Things?
The IoT is about attended and unattended devices, small devices and large ones, simple devices and complex ones. Sensors are critical. Perhaps the ‘thing’ is a helicopter engine communicating temperature, RPM, oil pressure, etc. The ‘thing’ may be internet-connected biosensors next to a soldier’s body and imaging devices on his helmet. Things in the IoT may be as simple as thermometers or as complex as earth observation satellites.
In the IoT, things can publish data about their state. Humans and applications can then use that data to interact with those things. When applications are interacting with each other, the term, Machine-to-Machine (M2M) applies. Thermostats and mechanical governors are precursors to M2M, but M2M introduces new elements: remote action, machine networks and computer intelligence. The potentials and consequences are just beginning to be appreciated.
The IoT’s rapid growth is enabled by the rapidly falling size, cost and power requirements of sensors and wireless internet connections. The growth is driven by applications. Makers of things, seeing the cheap wireless sensors, naturally begin to think in terms of embedded devices which interact with apps that connect to mobile devices via cloud computing services.
The IoT relevant to geoint may be consumer products that are directly usable by or adaptable to intelligence applications, or they may be special products developed for intelligence. The consumer products will be far less expensive and will far outnumber the special intelligence products, though, and thus most of the IoT data used for intelligence will come from consumer devices and applications ‘repurposed’ for geoint.
Where Does the ‘Where’ Information Come From?
When people think of locationaware devices, they immediately think of GPS devices (which are sensors), but there are other ways of sensing location. Some mobile device location systems determine location by calculating distance between a phone and nearby cell towers (using precise timing of signal latencies) or by sensing proximity to WiFi points of known location. Cell phone cameras can read QR codes affixed to buildings, buses, products or posters. Applications in logistics use RFID chips and other near field communication (NFC) approaches. Also, technology exists to match patterns in smartphones’ images of streetscapes or building interiors. As big databases of such images become available, provided by millions of users, this is likely to become a common way of determining location.
How is IoT ‘Where’ Information Communicated?
What good is sensing location if you can’t communicate location? Communicating simple latitudelongitude coordinates isn’t complicated, but computers expect consistency. The solution, of course, is to use standards. The point profile of the OGC Geography Markup Language (GML) Standard and the coordinate parameter of the OGC Open GeoSMS standard define concise rules for: coordinate order (latitude then longitude); whether these numbers are to be expressed as floating point numbers or degrees, minutes and seconds; whether coordinates are separated by a comma or a space; accuracy information; what coordinate reference system the coordinates are based in; and so forth. As the market matures, more and more app developers are realising the market value of interoperability, and they are implementing these standards rather than using ad hoc or proprietary encodings and interfaces. Ad hoc (‘custom’ or ‘bespoke’) and proprietary interfaces and encodings will forever require custom integration as systems evolve, while standards enable ‘plug and play’ into the future.
With or without standards, it is relatively simple to set up an application that requests a coordinate pair. The encodings and interfaces for other kinds of spatial queries are much more complex. A client and a server still need to ‘speak the same language’ if the server is to respond to the client’s request for services that calculate things like proximity, area, trajectory, probability, line of sight, etc. Fortunately, open standards that can be used in such query/response applications have been developed by the OGC membership in the last decade or so, which means that developers can implement free, well proven and widely used specifications to provide these capabilities. Widespread implementation by vendors means that many plug and play options are available for adding software components and connecting to other systems.
Communicating ‘where’ details about sensors, adds a new level of complexity, but here too, standards are available. The geoint community’s need for Observation Fusion has helped guide the OGC’s development of the OGC Sensor Web Enablement Geointelligence NOV – DEC 2013 30 Standards (SWE) family of standards. SWE standards allow users to assess the fitness for use of observations and to allow accurate processing on the sensed information to create derived information suitable to a user’s needs. Observation Fusion involves merging multiple sensor measurements of the same phenomena into a combined observation.
The IoT’s usefulness in geoint depends to a great extent on being able to fuse IoT information with information gathered from other geoint sources and from geospatial intelligence disciplines that focus on information of other kinds.
Fig. 2: Deployment scenario3 for OGC Sensor Web Enablement (SWE)
An assessment of SWE was conducted recently by Envitia under contract by the Defense Science and Technology Laboratory (DSTL), Advanced Geospatial information and Intelligence Services (AGIS) research programme within the UK Ministry of Defence (MoD). The study on SWE Implementation Maturity concluded, “The SWE framework provides significant benefits for supporting the integration and fusion of a wide variety of assets, and readily enables a system that is able to sense and react to threats or opportunities.”
Current Work in IoT Standards
The SWE standards are comprehensive, designed to meet virtually all types of communication between all types of sensor systems. Their necessary complexity is an obstacle, however, in meeting the needs of the IoT world, which typically involves low cost mobile devices on limited bandwidth channels. Also, IoT application developers usually have not had years of training in geospatial and sensor system communication, so the standard, an interface and encoding specification, needs to be readily understandable.
To meet IoT market requirements, lightweight profiles of the SWE standards are being developed by the OGC Sensor Web for IoT Standards Working Group (SWG). Members of the group have implemented a prototype they call the TinySOS service (Fig 3), a web server hosting a light-weight profile of the OGC Sensor Observation Service (SOS). With a pared down interface based on SOS, the devices become self-describable and interoperable, and the observations collected from the device are accessible via the internet as soon as they are produced. With lightweight devices and lightweight software, a multidevice sensor web can provide real-time sensor data streams with high aggregate spatial and temporal resolution.
Fig 3. The system architecture of TinySOS service.
The OGC Sensor Web for IoT SWG has also prototyped a new RESTful2 interface that allows communication through the lightweight JSON protocol. The interface implements CRUD3 (that is, create, read, update and delete) functions. SenseBox4 is a generic hardware and software framework that can be set up for different kinds of applications. It has been evaluated, for example, as an air quality measurement station and as a device to count cars in a Smart City environment, using an attached ultrasonic sensor (Fig. 2).
Today, most sensors have proprietary software interfaces defined by their manufacturers. This situation requires significant investment on the part of developers with each new sensor or project involving multiple systems and on the part of the providers of sensors, gateways Fig. 2: Deployment scenario3 for OGC and portals or services where observations are used. Standardised interfaces for sensors in the IoT will permit the proliferation of new high value services with lower overhead of development and wider market reach. It will also lower the cost for developing sensor and gateway providers. The geoint community clearly has a stake in seeing commercial development and deployment of open standards for the IoT.
IoT gaps are being addressed in other OGC working groups as well. The recently chartered GeoServices REST SWG, GeoSPARQL SWG (see Luis Bermudez’ OGC blog post, “Is the OGC Playing with Linked Data?”), RESTful Services Policy SWG, IndoorGML SWG, GeoPackage SWG and GeoSynchronization 1.0 SWG all address requirements that are directly or indirectly related to the IoT. The OGC’s OpenPOI Registry has recently been put online to demonstrate the value of an open PoI standard that makes it possible to integrate different sources of PoIs and enable quality analysis and other functions.
The recently completed OGC Web Services Phase 9 (OWS-9) Testbed Activity was structured around scenarios that were developed in part with attention to the needs of the geoint community. OWS-9 resulted in Engineering Reports (available at www.opengeospatial.org/standards/ per) documenting new standards technology. Some of these reports begin to fill IoT interoperability gaps, addressing topics such as semantic mediation, mobile apps, data provenance and quality, and single point of entry global gazetteer. Sponsors of the current OGC Testbed 10 have developed scenarios and use cases that are similarly influenced by requirements of geoint and the IoT.
The Importance of Coordination and Participation in Standards Development Organisations
The OGC has alliances with many standards organisations. These alliances are necessary because without such collaboration, many opportunities for improved interoperability would be overlooked. Often what is more important than formal alliances, however, is active cross-participation by members. Engineers who participate actively in OGC working groups and in other standards organisations’ working groups, provide the most important link between those organisations’ efforts.
Fig 4. The SenseBoxcounting cars.
Governments can play an important role in providing requirements, as they do in OGC testbeds. Military planning organisations are known for big scenario development and war gaming exercises, and these frequently produce use cases intended to guide procurements. The use cases are actually much more usefully applied in standards development than in procurements, because standards strongly influence product development. Government users of technology benefit when vendors compete to provide the technologies that governments want. Vendors will implement commercially valuable standards, but their desire to implement is even stronger when governments make it known that the commercial standards will be written into procurements. Participation in standards organisations’ testbeds and pilot projects gives governments and vendors opportunities to prototype interoperability solutions and test compliance and certification programmes.
In an emerging market domain like IoT, many of the new tools and methods come from new, small companies. They often participate in standards activities to stay a step ahead of their competitors. Government technologists who work with this innovative class of developers gain expert technical support as well as important market intelligence that can guide government technology strategies.
Today’s geoint is focussed on real-time monitoring of activities, events and time-critical transactions facilitated by open standards. Soon the world of geoint will be inextricably connected to the rapidly evolving IoT world.
References:
- https://en.wikipedia.org/wiki/List_ of_intelligence_gathering_disciplines
- https://en.wikipedia.org/wiki/ Representational_state_transfer
- https://en.wikipedia.org/wiki/ Create,_read,_update_and_delete
- Bröring, A., A. Remke & D. Lasnia (2012): SenseBox – A Generic Sensor Platform for the Web of Things. In: LNICST, Springer, Volume 104, Part 5, pp.186-196
