A substantial number of new Consumer Smart Services delivered by a Smart Phone, or in Car Systems, rely on the Position of the user relative to Positioning of a resource, such as a Restaurant, to work. It seems simple, and its translation into full blown IoT commercial systems seems straight forward, but is that really so? Is the representation of key features in an App ‘Map’, or from a Blueprint of a Building, the same as that of a Geospatial map?
The answer is obviously not, but in marking the site of a restaurant on a road for directions, as an example, Google Maps provides all the accuracy required. In comparison, a utility company relies on the details and accuracy that a conventional Geospatial Map provides for the Service Management of its widely deployed Assets.
Industrial Internet and Industrie 4.0 initiatives in creating and deploying Digital Twins is one example of the factors bringing the requirement for good quality ‘Position/Positioning’ into focus. The rational for a digital twin connected to physical versions in the real world is to gain a direct comparison between operating conditions experienced versus the theoretical assumption. As such the operating conditions affecting the physical versions are a critical factor. Geospatial maps provide a great deal of extra information about the surrounding terrain that may well be affecting different physical versions in different ways as well as explaining the deviations from the expected Digital Twin predictions.
Many of the large complex machines in the first wave of Digital Twining are also mobile; Locomotives, Jet Engines, etc., all bring the need to include the data on position. What happens if all the Railroads where to send the position of their Physical locomotives to the Digital Locomotive Twin using their own representational maps or drawings?
The Geospatial industry refers these captures as ‘Scans’, and of course they are usually unique customized ‘representations’ that will need reinterpreting, and as well as being very large data files to have to send. Assuming that the Scans are successfully transferred, and integrated, (not easy), then Position will be documented, but in analyzing the data the contextual Positioning becomes important. Positioning refers to the impact of the environment around the Position, as in the contours of a map detailing if the position is a locomotive working on flat geography, or hills, as one example.
Positioning is as vital for most data processing as Position; even in static machinery it can be the simple relationship to other machines, such as electro-magnetic interference impacting hospital BMI scanners. Reduced voltage supplies and brownouts may need to be tracked, and of course there is the question of Service Engineers access, amongst a host of other positioning factors.
A great deal of the commercial value in a Digital Twin lies in the comparison of the theoretical operational data with the actual operating data experienced by a range of Physical Twins. Understanding the deviations to enhance the design is difficult if there is no Physical Positioning data to provide the context for the eagerly sought ‘real’ data.
The diagram illustrates clearly the difference between a Geospatial map on the left with additional context on Positioning and a Scan representation on the right which contains a great deal, (too much), data of little significance to the Positioning context.
The Scan on the right was designed to be of great value to the Rail Company’s own Maintenance Operations showing the necessary detail of the installed Assets in context, or Positioning, to the use that they need to make of the information. Almost all Enterprises will have such Scans as the traditional manner of capturing and storing data in separate operational activities; and, many Chief Engineers will confide that that even internally they find it difficult to relate, or integrate, such Scans together.
The example below shows, on the left, the representative Scan of the installed system, probably created by the installer, whilst on the right is an example of the kind of blueprint created by the architect. The Service Engineer is expected to integrate in his/her mind the two in order to locate physically the elements that need maintenance. Unless personally familiar with the offices and installation then this is a difficult task to achieve before work can even start. This problem has existed for many years, and has made ‘Service Engineering management’ a prime target for IoT deployment.
Statistics on the maintenance of Building Management Systems suggest that between 10 and 30% of on-site time is spent on finding and gaining access to the item requiring service attention in a Building. The complexity of systems built into a large modern office block, and the separation of installation from maintenance, plus different security key holders for different floors, or zones, all result in a pile of different Scans using different formats, data, and scales.
As IoT is increasingly understood to bring the new working practices across interconnected Business networks of devices and resources, then the sharing and integration of data moves beyond the challenges illustrated at an enterprise level. Add the additional importance of ‘pictorial’ Graph User Interfaces to simplify the presentation of complex data and overall the importance of Geospatial becomes not only clear, but also vital.
Smart City projects with public, and private, participation across a substantial geography, have made the use of Geospatial data for position and positioning a critical success factor.
The Verve Smart City Project in Manchester, backed by the UK government, is an excellent case study. A consortium of 21 partners including many leading Technology Vendors are working to deliver; “CityVerve’s ‘platform of platforms’ treats the city as a living breathing organism by giving it a technology layer that acts as a central nervous system; smartly supporting and connecting independent systems and applications”.
With a focus on four key areas; Health & Social Care, Energy & Environment, Travel & Transport, Culture & Public Realm the amount of data that users, Public, Private and Personal, will create, share, interact is huge, and much of it will require integration into Services. And for Smart City to function in an integrated manner Position and Positioning will lie at the core of much of the activities. The diagram below shows that for Services Integration it will be necessary to not only define the Geospatial location of the building, but also to expand the building using Geospatial data to be a common reference data source for the internal geography.
There are specialist providers of the tools to provide detailed Geospatial mapping at Building level with the addition of context data related to each Asset and locations. The resulting ‘mapping’ provides a rich data capability in a common format that can be shared between Services companies to allow IoT devices to be powerfully augmented with both Geospatial and contextual data. The following diagram is a screen shot taken from the Verve Smart City project illustrating this capability.
Manchester Smart City Project Verve showing IoT Devices locations combined with context data within a building using the capabilities provided by the UK company Asset Mapping
Any type of Data Integration has always led to a substantial effort through various technology alliances to determine standards, and sadly usually the result with be more than one. Fortunately Geospatial is already standardized, and has been for hundreds of years, around the use of Latitude and Longitude with almost the entire surface of the earth mapped in this manner to extraordinary high standards of accuracy. More recently the recognition of the need to use Geospatial data in Technology systems has resulted in the founding of some key enabling organizations.
The Open Geospatial Consortium (OGC), an international voluntary consensus standards organization, originated in 1994. In the OGC, more than 500 commercial, governmental, nonprofit and research organizations worldwide collaborate in a consensus process encouraging development and implementation of open standards for geospatial content and services, sensor web and Internet of Things, GIS data processing and data sharing. https://en.wikipedia.org/wiki/Open_Geospatial_Consortium
A further practical aid comes from the OpenSensorHub who offer the following definition of their activities; “OpenSensorHub is a license free, open source software platform for geospatial (FOSS4G) sensors that allows you to easily, rapidly and affordably network sensors into a seamless SensorWeb of real-time, location-aware, interoperable, web accessible services. With OpenSensorHub, these OGC compliant SensorWebs can be enabled across all manner of space-based, airborne, mobile, in situ and terrestrial remote sensors — including your basic mobile device. OpenSensorHub finally makes it possible to integrate location-aware sensors into the geospatial mainstream.”
Google Maps are of course one of the best-known sources to add mapping to a project and they provide a guide to using their Mapping products to assist first time users. Details can be found in Storage.Googleapis here. For those requiring greater detail and accuracy in features there is GeoMesa, an open source extension built on Apache Accumulo supported on Google Cloud Big Table with access via Apache HBase Api. GeoMesa running on GeoServer fully supports the Open Geospatial Consortium standards, OGC, and further details are here.
‘Mapping’, in the broadest sense of the word to include including Architectural and Engineering drawings, has built over hundreds of years a huge library of documents. Most, created with little thought that they would ever need to be shared outside the confines of those directly working on and familiar with the projected use.
IoT connected smart devices with built in GPS are a significant game changing moment in the use of ‘Mapping’, and the consequences require new thinking as to the role of any documents that incorporates positioning. The tools are available to make use of high quality, high accuracy Geospatial data, and to be able to readily exchange and share the data between Devices and Services. The biggest barrier appears to be the understanding the need to do this!