Introduction to UOS Architecture White Paper

Introduction to the PlanIT Urban Operating System™

Architecture

June 2016, Vers ion 18

In t r o d u c t i o n t o P l a n I T U O S A r c h i t e c t u r e

© 2016 LIVING PLANIT SA ALL RIGHTS RESERVED. 2 of 51

The content contained herein includes confidential (non-public) information including intellectual property relating to creations of artistic works, inventions, business policies, practices, methodologies, data, symbols, names, images and designs used in commerce and details of commercial relationships with third parties. All such information is the sole property of Living PlanIT S.A.

Living PlanIT asserts its rights to the following Trademarks: PlanIT Edgeless Computing™, PlanIT Urban Operating System™, PlanIT UOS™, PlanIT OS™, PlanIT Crumbs™, PlanIT PlaceApps™, PlanIT Valley™, PlanIT Assurance™, PlanIT Labs™. Any reference to these names in this content shall be considered as an assertion of these Trademarks.



Contents Introduction to PlanIT UOS ...................................................................................................................... 5

Urbanization and Emerging Technologies ........................................................................................... 5

PlanIT UOS in the Context of Future-proof Cities ................................................................................ 5

Living PlanIT ......................................................................................................................................... 6

PlanIT UOS Overview ........................................................................................................................... 6

PlanIT UOS Architecture ...................................................................................................................... 7

Sensor/ Actuator Network Layer...................................................................................................... 8

Controls Layer .................................................................................................................................. 8

Supervisory Layer ............................................................................................................................. 8

Applications (PlaceApps) .................................................................................................................. 9

Benefits of PlanIT UOS Architecture .................................................................................................... 9

PlanIT UOS in Practice ........................................................................................................................ 10

PlanIT UOS and the Distributed/ Cloud Architecture ......................................................................... 11

Controls Layer Distribution ............................................................................................................ 11

Controls Layer Cloud Deployment ................................................................................................. 12

Supervisory Layer Distribution ....................................................................................................... 12

Supervisory Layer Tiering ............................................................................................................... 13

Supervisory Layer Cloud Deployment ............................................................................................ 13

Supervisory Layer Hybrid Deployment ........................................................................................... 13

Leading Ideas for a Sustainable Urban Future ............................................................................... 13

PlanIT UOS Architecture Features & Considerations ............................................................................. 14

Key Features ...................................................................................................................................... 14

Unified, Shared Model ................................................................................................................... 14

Data Architecture ........................................................................................................................... 14

Data Management ......................................................................................................................... 15

Data Access .................................................................................................................................... 15

Publish-Subscribe Interface (Near-Real-Time Data) ....................................................................... 16

Business Rules Engine and Framework .......................................................................................... 16

Scalability ....................................................................................................................................... 17

Security .......................................................................................................................................... 17

Privacy ............................................................................................................................................ 19

Multinode ...................................................................................................................................... 19

Analytics ......................................................................................................................................... 21

RTC (Real-Time Control) ................................................................................................................. 25

Modeling Services .......................................................................................................................... 27



Information Traceability and Rights Management ........................................................................ 27

PlanIT UOS Capabilities Summary ...................................................................................................... 28

Deployment Models .......................................................................................................................... 29

Why Cloud Deployment? ............................................................................................................... 29

Why On-Premise Deployment? ..................................................................................................... 30

Why On-Premise RTC Deployment? .............................................................................................. 30

Why On-premise Core Deployment? ............................................................................................. 31

Why Hybrid Deployments? ............................................................................................................ 33

Hardware/ Host Strategy ................................................................................................................... 33

Interfaces and Protocols ........................................................................................................................ 35

Overview ............................................................................................................................................ 35

PlanIT UOS Architecture .................................................................................................................... 35

API (Application Program Interface) .............................................................................................. 35

DSI (Distributed Scale Interface) .................................................................................................... 36

SCI (Sensor & Controls Interface) ................................................................................................... 37

Standard Protocols ........................................................................................................................ 37

Adaptable Transports .................................................................................................................... 38

Existing Drivers/ Legacy Systems ................................................................................................... 38

New Drivers ................................................................................................................................... 42

EAI (External Asset Interface)......................................................................................................... 42

Open Specification Philosophy .......................................................................................................... 43

Innovation and Open Standards .................................................................................................... 43

Open Source vs. Open Specification/ Open Protocol ..................................................................... 43

References ..................................................................................................................................... 46

Appendix 1 – Recommended Privacy Policy for PlanIT UOS-based Solutions ........................................ 47

Appendix 2: UOS Prerequisites for Installers ......................................................................................... 48

Introduction ................................................................................................................................... 48

Overall Hosting Environment ......................................................................................................... 48

SQL Server Installation Type .......................................................................................................... 49

Network Access and Domain-based Machine Names .................................................................... 49

SSL Certificate ................................................................................................................................ 50

External User ID (OAuth 2/ Open ID Connect ID) ........................................................................... 50



Introduction to PlanIT UOS

Urbanization and Emerging Technologies

By the year 2050 more than 66% of the world's population is projected to live in cities with a continuing population growth estimated to add 2.5 billion people to the world’s population by that same year, unabatedly consuming the bulk of the world's resources (United Nations 2014). The world of government is changing amid increasing pressure to deliver to citizens, services that are not only economically sound, but environmentally viable and socially responsible. However, change must be bold and swift if local and regional governments are to meet the increasing demand for services in a way that engages all citizens. Therefore, a new form of communication and provision of integrated services underpinned by cyberspace are quintessential for the improvement of delivery and performance of future citizens. The emergence of Internet services and an “always-on” culture has simultaneously raised expectations for government delivery – particularly amongst younger citizens. Solutions are urgently required to manage city resources efficiently while also providing a platform for citizen services as a key enabler to economic and social development.

As with other sectors that have benefited from technological innovation, urban development and operations will be significantly improved through the application of converging methods and technologies including:

Systems thinking – design architecture and interoperability that enables elements of the system to

collaborate with others to maximize the use of resources i.e. surplus energy produced from

renewable sources stored in water systems and automotive platforms etc.

Product lifecycle design and management – application of manufacturing methodologies and

techniques commonplace in other industries that takes advantage of modeling and simulation to

design for future operations which in turn informs and enhances the design and fabrication of

complex assets i.e. simulation of urban physics, spatial relationships, materials, human ergonomics,

logistics and environment to predict outcomes and make informed engineering and design choices

that reduces lifecycle costs and enables the continued augmentation of environments to meet

users’ needs.

The Industrialization of the Internet (sometimes referred to as “Machine to Machine

Communication”/ “M2M” – or latterly the “Internet of Things” or “IoT”) – the Internet has evolved

from simple information sharing, through communication and collaboration and is now entering the

era of ubiquitous connected devices. These devices may be simple sensors or actuators, materials,

mobile devices such as smart phones or wearable medical appliances through complex machines

and infrastructure. Control systems are commoditized and replaced by network hardware that

connect, interrogate (sense), analyze and control (actuate) devices, in turn harvesting intelligence

that enables continuous improvements in the efficiency and reliability of city and citizens services.

PlanIT UOS in the Context of Future-proof Cities

This white paper explains the PlanIT Urban Operating System™ (“PlanIT UOS™” or “UOS”), the industrial Internet platform and principal infrastructure that is integral to successfully envisioning, retrofitting, building and managing cities in the 21st century (“Smart”, “Intelligent“ or “Living Cities”). This includes recognition of the need for continual evolution; the importance of clear metrics and analytics; the increased connection between urban dwellers and the buildings in which they live and work; a sense of possibility and openness; increased efficiency; generative structures that learn; agile infrastructures



that serve multiple functions and respond to environmental and other changes; and resilient systems that can recover without breaking down or malfunctioning and that resist obsolescence (Resilience Engineering Association 2014). Many experts and commentators cite Living PlanIT as being the leading contender in providing more considered solutions to the problem of smart urbanization. We thus envision Living Cities as generative, inclusive, agile, dynamically evolving and resilient.

PlanIT UOS provides the essential platform that enables networked sensors and actuators to be deployed at scale, coordinated through a unified and secure real-time control layer which also shares and collects data across the entire urban landscape. This time series data converges with PlanIT UOS spatial analytics to be mined for further insight enabling continual incremental efficiencies and applications that enhance urban services to drive economic, social and environmental development and new forms of human interaction.

PlanIT UOS also provides a set of data and application services that facilitates the leveraging of building and city facilities and information by applications known as “PlaceApps”, making them location and context-aware. This enables the application developer community to quickly and simply build applications in that urban context for delivery to citizens, governments, service providers, and real estate developers and operators alike.

This allows cities and its citizens to make better decisions about their use of financial, natural and human resources, thereby creating a more sustainable city and dramatically improving the level of engagement a city has with its citizens and creates the flexibility cities need to make them “future-proof.”

Living PlanIT

Technology

Living PlanIT is a technology company that created the world’s first Urban Operating System (UOS) which, in combination with the products it supports, unlocks the full potential of data to make cities better, safer and more vibrant places to live.

Recognition

Most recently, Living PlanIT has received the 2015 Global Smart Infrastructure Platform Visionary Innovation Leadership Award from Frost & Sullivan. Living PlanIT contributes to the Clinton Global Initiative on Smart Cities and Infrastructure, is a member of the UK Government's Smart City Ministerial Forum and board member of the Cities Standards Institute. The company has received numerous awards including “Best Investment in High Tech in Europe” from the World Investment Conference, “Technology Pioneer Award” from the World Economic Forum, “Business Internalization Award” from UK Government Trade & Investment, “Growth Excellence and Leadership Award for Smart City Projects” from Frost & Sullivan and both “Best Company for Innovation in Urban Development Technologies” and “CEO of the Year” from IAIR in 2015.

Scale

Living PlanIT has built an extensive partner network around the concept of a shared, unified approach to smart urban technology architecture in which machine intelligence moves ever closer to originating sources of data and control. We call this architecture PlanIT Edgeless Computing™ and it is implemented throughout the PlanIT Urban Operating System™, providing a framework for resilient and secure computer and systems architecture for digital and biological sensing, control, analytics, machine learning, applications and visualization techniques.

PlanIT UOS Overview

The PlanIT Urban Operating System is a standards-based middleware product that provides real-time sensing, control, spatial analytics, data integration, security, support and provisioning of ubiquitous context relevant applications for the Internet of Things. The UOS platform accelerates the development and deployment of urban technology and connected devices. It provides software-based flexible real-



time control, as well as supervisory control, data acquisition and lifecycle management. Its real-time and historic analytical functions, together with a comprehensive Services Oriented Architecture API, simplify the building and operation of advanced data-driven and control-based applications on a variety of end-user devices.

Living PlanIT primarily focuses PlanIT UOS on:

Living Cities/ Smart Urban Developments – the emerging market for increasingly intelligent,

sustainable buildings and infrastructure, whether deployed in new cities, major regeneration

projects in existing cities, or individual developments.

The Internet of Things – the “connected device” market, based on increasingly pervasive networks

and providing remote sensing and interaction with a wide array of embedded and mobile devices,

ranging from smart-phones to vehicles, to robotic devices, to sensor “motes”.

Because the majority of places where the Internet of Things will be successfully deployed are increasingly smart urban built environments, these markets are essentially convergent.

The majority of applications are delivered by a growing ecosystem of partners, within projects in which Living PlanIT is engaged, as well as directly through their own channels that look to drive specialized applications targeted at enhancing the design and delivery of smart cities and connected devices.

Living PlanIT supports optimized deployment of PlanIT UOS through the provision of professional services under the umbrella of PlanIT Assurance, which is Living PlanIT’s professional services and related deliverables pertaining to the models for economic, social and environmental development, enabling technologies and systems, design, implementation and operations of cities, urban development, infrastructure, and associated vertical applications. Services particularly germane to successful PlanIT UOS deployment are likely to involve activities such as Urban Network design, UOS infrastructure planning and commissioning, and operations and analytical support.

PlanIT UOS reduces the cost of providing control architectures in an urban context as well as advanced information and interaction management, in both private and public cloud contexts, by making extensive use of standard hardware and software components from partners. Further, by providing a unified and shared platform for all applications, sensors, and data, deeper insights are enabled because more naturally aligned information is available to interpret, in turn driving a richer history to provide predictive models and optimization. This means cheaper infrastructure, progressively more efficient operations and lower operating costs, and better consumer and user experiences.

PlanIT UOS Architecture

PlanIT Urban Operating System is sometimes described as the collision of next-generation software-based Building Management Systems, SCADA (Supervisory Control and Data Acquisition) and cloud computing. To put it another way, it provides a unified sensor data acquisition, real-time control, historical database, analytics engine, and application hosting platform for urban environments, or, deployed in a public cloud, for remote devices with sensing and actuation capabilities.

PlanIT UOS has been architected to allow flexibility in deployment and also to scale from a small/local controls scope to large scale domains, ultimately comprising entire cities. Examination of the architecture shown below helps to explain how this is achieved.



Broadly the architecture can be seen to have four distinct layers:

Sensor/ Actuator Network Layer

A unified, converged network which is enabled by the UOS but is not considered part of it. UOS communicates with devices in this layer to collect data, make decisions (sometimes with user input via applications) and issue commands to controllable equipment. In an urban environment the network will typically be a local/ metropolitan area network. The equipment at this layer is extremely heterogeneous in nature and may well involve legacy equipment which may include intermediate controllers.

Controls Layer

The ‘first layer’ of the UOS, deployed with network infrastructure. This provides the most distributed point of intelligence in the system, and provides the most time-critical responses to incoming data. It also is where the specific code (or Driver Applications) for interfacing with specific equipment resides if needed. Control Applications also reside at this level – these are managed through the supervisory layer of the UOS but run in the PlanIT UOS Real Time Control (or “RTC”) core to provide autonomous, immediate responses to control requirements, for example the control of a light or a motorized flap that forms part of an HVAC system.

Supervisory Layer

The ‘second level’ of the UOS provides higher level, more aggregated intelligence from individual building scale to an entire city or a fleet of distributed devices. This layer collects, manages and provides insight to data, ensures that data is propagated quickly to where it is needed and provides an Application Programming Interface (API) for applications to leverage. This is organized and optimized for shared use across multiple verticals and use cases (where its economic advantages are best optimized) and also for use by multiple shareholders, with a robust security model to ensure appropriate access to data and control capabilities.



Applications (PlaceApps)

These are enabled by the PlanIT UOS and may run in a context that is fully provided by the PlanIT UOS, but should not be considered part of it (although certain applications may well largely consist almost entirely of exploitation of the services that form the PlanIT UOS API). Applications enable users to interact with data and controllable equipment in the urban environment, subject to access granted by the security model. Applications are portable across UOS deployments, opening up a mass market for smart urban applications because the details of equipment interfaces are abstracted from the application by the UOS while the UOS is always the same consistent platform.

The PlanIT UOS SDK provides support for application developers, including platform-specific code libraries which facilitate use of the PlanIT UOS APIs (particularly those pertaining to security) and provide other useful functions which enable prevailing IoT models such as composite application development for mobile devices.

Benefits of PlanIT UOS Architecture

PlanIT UOS ensures scalability and reliability principally by careful control of distribution of functionality. In general the UOS seeks to centralize management but distribute execution. In practical terms this means that the Core layer of the UOS adapts equally well in scalable form to cloud, on-premise, and hybrid deployments, and the RTC layer provides true real-time performance with minimal latency and high degrees of autonomy due to its distributed nature.

The key differentiators of the PlanIT UOS architecture over traditional Building Management solutions are as follows:

A unified sensor network provides cost benefits of an ‘all-shared’ sensor and actuator infrastructure,

as well as richer insights through ‘naturally aligned’ data;

A common and shared supervisory layer enables optimum reuse of sensor data and control

capability across multiple use cases and guarantees data alignment for use by multiple stakeholders

with appropriate views driven by robust and concrete security;

Converged networks provide efficiency and better performance with contained cost;

Lower cost deployment through the use of commodity hardware and software;

Highly redundant architecture eliminates single points of failure;

Race-proven controls architecture and highly reliable network hardware helps ensure primary

reliability of control functions;

Control algorithms are centrally deployed and can be updated in real-time;

UOS scales to larger control domains through use of near-real-time data propagation;

Historical data allows for predictive models and continuous optimization of performance;

Abstraction models for capital equipment enable ‘pre-integration’ of hardware, substantially

reducing commissioning cost and risk while enabling more comprehensive control;

Consistent application API provides a mass market for applications, stimulating the ecosystem that

builds them and commoditizing the availability of functionality for UOS-equipped developments.



PlanIT UOS in Practice

This example illustrates how the UOS can be used to efficiently deploy Internet of Things techniques, increase the efficiency of the built environment, and leverage a diverse shared set of resources to support multiple verticals, while focusing purely on a very simple use case. In a representative environment many functions and applications would be supported by the same infrastructure, driving down both CAPEX and OPEX for building control, environmental systems, and user experience and convenience solutions.

Sensor Network

A set of sensors in a given room in a building constantly detect conditions and relay this information through the converged network to the controls level of the UOS. The controls level knows either through supported standard protocols or a device-specific driver application how to correctly interpret the data coming from the sensors. UOS ships with over 160 driver applications to facilitate integration.

Control Application

This information may well be used in the first instance by a number of Control Applications resident in the PlanIT UOS RTC which manages and supports these applications. For example an HVAC application will take into account factors such as temperature, humidity, air quality, weather conditions and occupancy, predicted or advised arrival/departure times of occupants, and energy cost and availability to determine whether adjustments to the current conditions inside the room are necessary.

Other Information

Some of this information is obtained from local sensors. Other information comes from elsewhere in the urban environment (or outside) and is relayed via the UOS Supervisory Level’s Urban Service Bus. The HVAC application when active runs continuously, taking account of changing parameters to determine – for example – the appropriate position of a motorized flap which increases the amount of heated/ cooled air ducted into the room – and/ or the velocity of any airflow-boosting fans fitted.

Algorithms

Mathematical algorithms for control underpin these control applications, which are usually built as the building is designed alongside choices about building physics and materials used. A modelling and simulation suite integrated with the UOS for comparator buildings can help with this initial optimization and design. The running algorithms can then be continually fine-tuned via the UOS (see below).

Supervisory Level Feed

In addition to these immediate control functions, information is also continually relayed to the supervisory layer of the UOS. This achieves two purposes:

The historical database is continually updated with what is being measured within the room and the

entire development;

Information required by other subsystems is relayed in near-real-time to those systems.

History = Prediction

The collection of history data allows for very precise forecasting and prediction to be achieved. For example, predicting when an owner is likely to reach home or what settings they will want for their climate control given outside weather conditions and previously observed patterns.

Urban Service Bus

The relaying of information to other subsystems is achieved using the Urban Service Bus. This employs a ‘publish-subscribe’ paradigm to allow other control applications to subscribe to information available in the system as a whole. For example, it’s likely that the control application which maintains the temperature and airflow in the main ducts of the HVAC system is physically separate from the one maintaining our room’s air-flap. But this latter application appreciates knowing when the air-flap is moved for any rooms connected to that duct, as it maintains a model of demand on the system so it can continually adjust its output to suit.



Applications

Our simple story doesn’t end there. Let’s say the apartment owner gets home and wants to make a change to the HVAC settings. The intended setting for this room is a variable held somewhere in the UOS and made available to the control application. But how can it be changed?

PlaceApps

This is where PlaceApps come into play. PlaceApps (the Living PlanIT term for user-facing applications in the urban environment) allow people to interact with systems. A PlaceApp for HVAC might run on a permanently mounted wall panel which looks like a traditional thermostat, and on a smartphone application, and on a TV screen… etcetera.

Service Orientated Architecture

PlaceApps are built using Service Oriented Architecture where much of the application content consists of services that are bound to simple UI elements, making it easier to write applications that run well on multiple devices. So via some PlaceApp the user makes a change, which is fed in near-real-time to the control application which starts to make adjustments. But the fact that the user made the adjustment at a certain time and from a certain location is also recorded so that this can be used later on to better predict the users requirements.

Portability

Applications written for one UOS deployment will work in other UOS-equipped developments, because the platform is consistent and the details of interfacing with specific types of equipment are abstracted from the application by the UOS. This opens up a mass market for applications as opposed to a model where development is bespoke and less efficient.

Context Driven Security

In addition, using context- and policy-driven security allows us to make the environment both more secure and easier to operate. For example, our ‘thermostat’ application may allow anyone in the apartment at the time to make adjustments, just like a thermostat operates today. As a convenient extension to this, we might allow anyone in the apartment to also make that change from their smartphone – ie. remote control. However only the owner can make changes to those settings when they are not in the apartment, and may be restricted from making certain settings if other people are occupying the apartment at the time to avoid inconvenience and possible risks. All of this logic is encoded as simple policy statements, which can be applied consistently to all apartments in the complex, significantly reducing the amount of security configuration required and in so doing making the environment more secure, because copying/ editing errors are eliminated.

Optimization

But even now there is a coda to our story. All of the algorithms that run the HVAC system together with every algorithm in the urban environment can be continually fine-tuned to perform more efficiently under real-world conditions. What-if scenarios and optimization techniques using artificial intelligence can be played against the history data collected. Evolutionary algorithms can help in constructing and evaluating a set of alternative control algorithms to evaluate against real-world data. Once such algorithms are found which perform better than the current versions, they can be deployed without downtime thanks to online update facilities built into the RTC core. This means that UOS-equipped buildings get more efficient in the first years of their life, not less. This continuous optimization of all urban functions drives efficiency, and reduces the environmental impact of buildings and what people do in them.

PlanIT UOS and the Distributed/ Cloud Architecture

Controls Layer Distribution

UOS integrates the controls layer with the network infrastructure to enable the running of the most time-critical functions at the edge of the network, minimizing latency and ensuring performance. This



provides for the isolation of ‘chatty’ information from the rest of the network (for example, ‘don’t send new data readings until a sensor value changes’). The UOS also runs within the security context of a local subnet, which forms an important part of the security framework. This solution also enables direct connectivity with non-routable networks and other connectivity types, including serial communications, non-IP wireless networks, and A-D and relay port connectivity.

This distribution also makes it relatively simple in most environments to provide redundant infrastructure, something hitherto unknown in the building controls market. For example a network device that provides control functions for one floor of a building can now be cross-coupled to another floor, so that if one controller fails the other can take over. The architecture is also inherently resilient in that control applications can function autonomously to maintain mission critical functions, even if isolated from the rest of the UOS network. Local storage allows buffering of historical data for many hours before any information is lost.

Controls Layer Cloud Deployment

While it is a rarer case, the controls layer can also be deployed in the cloud, generally collocated with the UOS supervisory layer. This is practical where the need to support short-range or non-routable networks is absent and where high-speed low-latency control is not required. The most common scenario for this pattern is where all data is sourced from data feeds (other services), applications (eg, on mobile devices) or smart IP-capable sensors or aggregators, and where there is still need for data stream decoding, mapping, and/ or transformation. RTC cohosts well with Core in this case to fulfil this requirement. It is also possible to cohost RTC in this fashion as a means of supporting real-time analytics (see section below).

Supervisory Layer Distribution

In an urban built environment, the supervisory system is also distributed. In general the UOS is likely to be distributed in ‘clusters’ around a development or city/ region, rather than centralized in a data center. The clusters will usually be located in an equipment room in a multi-tenant building and where needed a cooling plant can be integrated with the building HVAC/ district heating/ cooling system for maximum thermal efficiency and minimum investment cost.

This approach has several advantages. The clusters will operate autonomously (given power) if disconnected from the rest of the UOS/ urban network. Equally UOS clusters will usually be deployed with spare capacity, to be able to take on the most mission critical functions from another cluster if it fails or needs to be brought down for maintenance. When not used for redundancy, this spare capacity can be used for ‘roving’ loads such as analytics and simulation, or sold as compute capacity to office tenants or other partners, or the server throttled down to reduce power consumption.

Data redundancy is also achieved more elegantly than in the traditional ‘replicate the data center’ model. One copy of data is always stored in the local cluster, because this is where it was generated and will most commonly be referred to again. Equally at least one copy of data is stored in a location remote from the originating cluster. Finally, aggregated information is stored in synchronized ‘supernode’ clusters (larger than average clusters with more of the historical city data stored in them) in order to optimize performance of analytics services.

The least compressed, most ‘raw’ data (especially video imagery) is typically kept for forensic purposes for a few days only; it is usually kept local to the cluster, minimizing network load.

All UOS functions are designed to enable this ‘multinode’ deployment model and optimize the benefits presented by this physical architecture, while mitigating the disadvantages (such as avoiding database joins that are propagated over multiple dispersed systems). As functions can be redistributed across the architecture at will, this is considered to represent a ‘distributed cloud’ model, as the principal characteristic of location independence still applies.



Supervisory Layer Tiering

As has been noted above, UOS scales out by way of a distributed multimode model. Further tiers can also be added in a ‘vertical’ domain, aggregating functionality in a ‘pyramid’ topology. For additional optimization, the routing of information from one node to another does not need to follow purely hierarchical lines; the routing model can be continually tuned to meet the requirements of the specific deployment and applications in use.

Supervisory Layer Cloud Deployment

Certain solutions lend themselves better to a more classical cloud deployment where functions may well be deployed in a typical data center hosting environment. UOS also adapts to this paradigm, with the ability to scale up and out still being critical to the way in which functionality is deployed on multiple virtual machines to meet demand. These solutions are likely to be used most commonly in IoT solutions, and where the ability to carry a distributed local infrastructure is minimal; for example when integrating the UOS with streetlights, or when retrofitting single family homes.

For cloud environments from our strategic partners (Microsoft Azure and Amazon Web Services) the UOS is increasingly optimized, with a service bus design that takes advantage of cloud fabric services to improve inter-VM I/O. Upcoming releases will enable native fabric support, providing fine-grained and automatic scaling and helping to minimize cloud service charges where payloads vary significantly.

Supervisory Layer Hybrid Deployment

The UOS architecture further brings the opportunity for hybrid architecture, where lower tier nodes are deployed on premise (taking advantage of natural partitioning, where data generated locally is most frequently used locally) and higher tier nodes are likely to be cloud hosted, where the benefits of data center concentration and strong connectivity to the Internet are of more value and local affinity and the need for low latency is less acute. Very few IoT platforms provide such flexibility, but Living PlanIT believes that this will be the dominant architecture as canonical deployment patterns are established.

Leading Ideas for a Sustainable Urban Future

Deployed in association with an extensive partner and stakeholder ecosystem, the UOS is used by real estate developers, building owners and service providers to envisage, design, manufacture, assemble, operate, service, maintain and decommission buildings more efficiently, improving performance in terms of economic, social and environmental sustainability.

The smart infrastructure deployed in these developments (built around the UOS) provides a platform for both economic growth and for adding capabilities to these urban communities and cities on an ongoing basis through the development of value-add applications.

The data collected also enables a new style of integrated reporting for cities in which all stakeholders can receive accurate information on financial and nonfinancial (environmental, social, and governance) performance and the relationships between them. Through integrated reporting and PlaceApps using this information, city leaders and citizens can make better decisions about their use of financial, natural and human resources, thereby creating a more sustainable city. In addition this type of reporting and its associated PlaceApps will also dramatically improve the level of engagement a city has with its citizens.



PlanIT UOS Architecture Features & Considerations

Key Features

PlanIT Urban Operating System enables its target markets and differentiates itself from other offerings principally though the quality of its architecture, design and implementation, and in particular through a number of key features which are described below.

Unified, Shared Model

PlanIT UOS is designed to provide a flexible, adaptive, scalable architecture for implementing a shared sensor and controls network and unified supervisory layer which simultaneously supports all required verticals and applications, and multiple stakeholders. In an urban environment this may include but is not limited to landlords, management companies, local governments, utility companies, service providers, logistics providers, tenants, workers, residents, retailers, visitors, and customers.

An UOS instance is typically applied to a well-defined scope (a building, cluster of buildings, city and surrounding region, shopping mall, airport, rail station etc.) and is operated by a single entity for the benefit of multiple entities and applications. Multinode enables the selective federation of these entities to enable coordination at larger scale as needed. It is also entirely feasible to operate in the cloud as a shared-scope multi-tenant architecture which may or may not leverage multinode for scale, depending on the characteristics of the cloud infrastructure and the desired operating model.

In any case the use of such a model significantly drives down implementation and operating cost. For a single use case, a well-designed redundant UOS architecture is cost-competitive with traditional BMS solutions in terms of CAPEX, and provides savings over operational lifespans particularly considering the improved scope for optimization. Once multiple use cases are hosted and the benefits of sharing infrastructure, data, and sensors are exploited, the cost structures are significantly different. This does however often require a different approach to project budgeting and the need to recognize a shared utility.

The utility approach does however require a high degree of data transparency, and the ability to then appropriately secure access to that data and ensure the privacy of people about whom data may be retained. This is addressed in following sections.

Data Architecture

For data to be useful in a shared utility model it is necessary for it to be well, and consistently described, and a lot of time and effort is frequently expended in analytical systems in ‘cleansing and aligning’ data to be able to make data from disparate sources integrable and useful. UOS addresses this at source by aligning all data to a model which is consistent for the UOS instance.

In order to allow a wide range of scenarios and requirements to be addressed, this model is customizable. However if additionally recommended UOS canonical and operating models are followed or largely followed, then the data will also be globally consistent, increasing the sell-on value of such data as well as its ability to be combined with other similar sources, whether local or remote.

The UOS data model for resources provides an object, type, and unit model to ensure data alignment. Data model classes can be further decorated with an extensible set of attributes, allowing for further data and metadata to be captured by the UOS.

In addition, UOS identity mechanisms support extensive user profile information which is also extensible through attributes. As well as enabling user profiles the user data also includes the capture of UOS and



application usage or activity; this is a first class source of urban data in many scenarios, and also means that it is possible to run a real-time CRM system on top of UOS. This is particularly useful for retail or any other scenarios where services need to be rendered to end users.

Data Management

UOS manages its data using industry standard RDBMS solutions. The use of RDBMS bucks the industry trend towards ‘no SQL’ approaches such as Hadoop , although UOS supports an application pattern for export of data from UOS nodes to enable interoperation with Hadoop-based analytics where needed. The use of RDBMS provides significant strengths in terms of added layers of infrastructure security, resilience, the ability to tune performance to circumstances, integration options, and additional features, and the design of the UOS database has been carefully optimized to hybridize the advantages of ‘no SQL’ and SQL-based approaches, leveraging the sophistication of SQL to provide a flexible metamodel for rich metadata-based queries, while keeping the simplicity of ‘no SQL’ based approaches to enhance performance for the most commonly used datasets.

We do not generally advise customers or partners to carry out their own operations directly on UOS tables, although we do provide full documentation of data structures. Users are recommended to use PlanIT UOS APIs (including data lifecycle management APIs) for all operations. This maintains the full integrity of the UOS security model and also allows UOS automation and API-driven solutions for maintenance of the SQL environment.

Multinode architecture handles the marshalling and replication (if desired) of data between UOS nodes as part of the overall data management solution. Data Lifecycle Management features are supplied as part of the product and are being extended with future releases.

The UOS SQL instance can be reused in parallel for other applications with the usual caveats about potential cross-application impact if resource consumption is heavy.

In a later UOS release an application persistence service will be provided to enable managed database sharing with the option of leveraging the UOS security model as part of the continued development of application hosting (class 2) APIs. This can be seen as a logical extension to the application activity logging already supported by UOS.

Data Access

Having built this construct to manage significant volumes of aligned and managed data, how does an application (or a user) gain access to it?

The primary method for applications is via the open data access API. The UOS was the first IoT platform to support the oData standard, and that choice has been followed by other companies. oData provides a database-query-like syntax enabling data queries of substantial complexity to be made from a REST-based interface which is conceptually and structurally simple. In addition UOS provides a URI-based mechanism for defining location through logical hierarchy, and the two mechanisms can be freely combined in order to obtain information of interest.

This means that the UOS has a generic data access API, which greatly simplifies the work of the application programmer. More explicit and contextual APIs may also be supported as part of functional APIs (see section on Interfaces below).

UOS also supports the emerging HyperCat specification for providing data catalogues (Living PlanIT contributed to the development of this specification). UOS automatically publishes HyperCat catalogues when this function is activated, and catalogues published are automatically filtered in line with UOS security policy settings (see below), helping to ensure that such catalogues do not become a source of data leakage.

It should be noted that using the oData based data access APIs are always subject to the UOS security model, which filters results silently to only the information requested and to which the application/ user/ device/ time/ place has rights.



Publish-Subscribe Interface (Near-Real-Time Data)

A very common requirement in IoT and smart city applications is to ‘get the right data to the right people and place at the right time’. In common with the high emphasis which UOS places on enabling real-time functionality, extensive support is provided for marshalling data in near-real-time via the UOS publish-subscribe mechanism.

Publish-subscribe is a well understood paradigm, but the UOS solution is differentiated in a couple of ways. Firstly it supports server-level filtering of results, leveraging both the UOS location hierarchy and a significant subset of oData syntax (since oData was not designed for this use certain functions do not make sense in this context). This provides a very high degree of symmetry between data access and subscription filtering which is highly useful for certain application patterns. More importantly, this means that applications do not have to do the work of filtering and discarding data not required themselves, and where filtering requirements for multiple subscribers are common, economies of scale can be exploited.

Secondly the filtering takes place at the first PlanIT UOS Core (“Core”) node to receive data. This means that only filtered data is passed across the network, significantly reducing network and IO traffic throughout the entire system and contributing to UOS performance.

As with the oDdata and all other data access mechanisms in UOS, information retrieved is filtered silently to only the information requested and to which the application/ user/ device/ time/ place has rights. In the case of subscriptions, this means that subscription results which are not authorized will not be sent to the endpoint, which is not an error condition. If UOS logging is turned on, authorized users will be able to audit why data was not sent.

The original implementation of pub-sub in UOS required an endpoint equipped with an http listener to receive data. For mobile devices and other endpoints with a non-persistent IP address, a more complex solution provided notification via multiple channels of a subscription match, allowing the device to retrieve the data it had missed via the oData APIs, exploiting the symmetry in syntax between the two subsystems. In release 4 however, a websockets-based transport effectively replaced this solution. Websockets enables a persistent connection to be established with a mobile device, which in the event of network disruption can remake the connection, and therefore subscriptions can be reliably delivered. As a further extension of the websockets transport, a UOS application messaging channel is also available via a class 2 API. This provides similar capabilities to mobile platform notification services but is not subject to non-deterministic delivery and throttling by Apple or Google.

Business Rules Engine and Framework

In order to handle more complex event processing than is achievable with publish-subscribe, a business rules engine and framework is available within UOS Core. Business rules can be invoked in three ways:

As a result of a subscription match via the pub-sub mechanism;

Via API invocation;

Via a scheduler.

The nominative form of business rules is to be invoked as a result of subscription match, enabling near-real-time eventing behavior. The business rule is passed relevant parameters and can then carry out arbitrary actions leveraging the UOS API and any other resources it has access to. This allows for more complex near-real-time behavior than with pure pub-sub, which is limited in its scope to acting only on the data coming across the bus at the time.

In fact the integration of the two subsystems is sufficiently close, that the default action for subscriptions (to send the matching data to the relevant endpoint) is now implemented as a standard business rule. However as noted above, other standard or custom rules can be used alternatively.



Custom business rules are implemented in UOS out-of-the-box using Microsoft’s Workflow Foundation. However in an upcoming release it will be feasible for administrators to integrate alternative business rules engines of choice as required.

Scalability

As well as providing significant deployment flexibility and redundancy/ autonomy options, UOS is designed to scale upwards and downwards. It is feasible to use UOS as a control solution for a single piece of capital equipment using PlanIT UOS RTC, and if it is required, to provide API access to those control functions. It is even possible to collocate RTC and Core onto a single embedded host device to provide a compact and encapsulated solution.

Conversely UOS Core can be deployed in the cloud (even distributed across multiple cloud data centers or regions using Multinode) to address large and/ or high level requirements such as providing the open data hub for a city, country, utility or multinational. Where it is necessary to provide remote adapter framework or control logic capabilities, it is possible to collocate RTC instances in these cloud environments, although the benefits of minimizing latency and increasing autonomy from continuous internet connectivity though more localized deployment should be taken into account.

Considerations for different deployment patterns are reviewed below.

Security

For successful urban technology deployments, the criticality and value of data collected and the importance of control functions mean that being able to secure these assets is crucial, to protect from anything from data theft, to privacy incursions, to denial of service and disruption attacks, to sabotage of infrastructure, potentially as part of a more physical assault.

Ultimately the UOS is principally an ICT construct, and therefore traditional and well proven techniques can be brought to bear as part of a holistic defense-in-depth approach. It is also fair to say that the first line of defense for appropriate use of data and control assets is likely to be with the applications which access UOS, and for this reason a well-run UOS instance will include the certification of applications; Living PlanIT and its partners provide a generic version of certification as a service.

However even given appropriate security of core infrastructure and the UOS platform ‘perimeter’ and having ensured well-behaved applications, the UOS still has an open API and as such plays a key role in ensuring that only the right data and capabilities are exposed to the right customers. Critically, we do not allow any non-encrypted traffic into or out of UOS Core, and we maintain a minimal attack surface through the use of a very restricted set of ports and generic standards-based APIs. Avoiding intrusion at multiple levels and steering operators and integrators away from insecure choices during installation and configuration is also an important part of the security model, as is obfuscated code and a mature licensing solution to avoid IP theft, spoofing, and extended unauthorized access to materials. We also enable heuristics and pattern analysis which can be important in detecting intrusion and tampering attempts.

Additionally, while it makes no sense to try to enforce a complete identity schema on our customers and partners, UOS has to provide the building blocks for a well-defined identity scheme and the means of ensuring appropriate claims are made to the security solution. We achieve that via an identity framework which enables interoperation with other solutions via standards; specifically Open ID Connect, based upon Oauth 2 (earlier versions of the UOS provided our own composition of Open ID and Oauth).

One challenge in the urban environment comes with scale and most traditional authorization systems depend on explicit allocation of rights by user group and/ or individual user. As scale and scope increase, the probability of there being holes in the security settings which can be exploited increases exponentially and represents a prime risk when modifications to those settings are being made.



A further challenge is that the security which should be applied is usually highly contextual, depending on identity, application, device, location, time, and potentially other factors rather than the more static identity-only based approaches.

For this reason the UOS security model has been designed around open standards as a claims- and policy-based solution. Essentially policy is defined, either using the PlanIT UOS Administration tool or more likely by expression in ODRL (Open Digital Rights Language) syntax. This means that it is relatively straightforward even to translate contractual access terms into security policy, and indeed a pilot with a couple of partners along these lines is underway. This syntax as a minimum requires the application accessing the UOS to be well defined as a claim, and supports other optional claims such as identity, device, location, and time. The policy, which can still include the structure of groups and address individual users (or devices, or locations or…) if needed, is then compiled to guarantee that appropriate settings are enforced for the particular conditions. Such an approach is inherently more scalable and robust than traditional approaches.

The following chart shows the extensive benefits in terms of reduced cost and complexity of managing security with a policy-based approach. It demonstrates that as the size of the environment and the population increases, if the policy rules were defined sufficiently in the first place, there is no need to increase the number of security primitives; they do not scale linearly, they are flat. In comparison, for traditional access control approaches, the number of primitives scales exponentially, and rapidly becomes unmanageable and prone to transcription errors which are exploitable.

© 2015 Living PlanIT SA – All Rights Reserved Strictly Confidential2

Policy-based security allows security properties to be managed accurately as the domain gets large

The following example shows the number of combinations of user and resource that need to be configured as scale increases with traditional access control configuration, and policy-based paradigms.

Assumptions for this example: an apartment complex, 2.5 residents per apartment, 40 sensors per apartment. Rules are set per sensor-resident combination to allow for subtle and well-defined scenarios (such as: an individual can adjust HVAC settings if he is in the apartment, but can only adjust remotely if he is the tenant).

With policy based security the relationship between sensor and resident is defined by context so at worst case, only one rule is needed per sensor (by using sensor classes or resource attributes this can be many less). With traditional approaches, rules have to be cut-and-pasted and edited to provide correct settings, which are also inherently more ‘static’ and subject to change. This increases the risk of security setting errors dramatically.

How does Policy-based Security help?

Number of Apartments

Traditional Paradigm

Policy-BasedSecurity (worst case)

1 100 40

10 10.000 40

100 1,000,000 40

1000 100,000,000 40

Security settings in the UOS are not necessarily black-and-white in their impact. For something that can be controlled, certain capabilities may be available to a particular user and others not. For example if I am a guest in someone’s apartment, I might be able to adjust the thermostat from a wall interface for immediate effect, but cannot reprogram their timer-based settings for temperature, whereas if I were the owner or their spouse, I could. Depending on local policy (which may be set by the developer,



landlord, management company, occupier or a combination) I may or may not be able to change the immediate settings from my mobile device depending on who I am and where I am currently located.

More importantly, when retrieving data from UOS the record set returned is filtered according to security policy. If I am allowed to see historic temperature sensor readings for my apartment and common areas in a building, but not for other tenants’ apartments, then if I make a query to show me historic values for the entire building, I will be returned only the relevant data. Where anonymized/ summarized values have been calculated (e.g. average sensor readings by floor) it is likely I would be shown these also providing they were in the scope of my query.

The policy-based authorization layer in UOS will be extended in the near future to enable data broker facilities, where the same approach dynamically defines access to data wherever it resides, opening up access to more diverse data sets while still providing data owners with the ultimate in control over their data sharing policies.

Open standards supported by the UOS security model include SSL/ AES, Open ID Connect, Oauth 2, and ODRL.

Privacy

While the specific applications, scenarios, and settings in use on an UOS instance determine the level of sensitivity, in many cases information which is potentially sensitive from a privacy perspective to certain stakeholders in the ecosystem (particularly residents, workers, customers) will be held in the UOS.

The first step to ensuring their privacy despite this information being retained is in data modelling (see data architecture above) to ensure that primary identity characteristics are held in the system no more than is necessary. A second step may involve the partitioning of identities; there is no need for all activities a user may undertake in the city to be necessarily associated with the same user ID, and fragmenting such activity can positively help manage privacy concerns.

Thirdly, it is critical to ensure the strongest possible security for data retained (see security section). Data Lifecycle Management settings can be used to anonymize data when information at the individual level no longer represents a material benefit to the individual, or the urban platform in general.

And finally, a well-defined privacy policy which protects and warrants the rights of effected stakeholders is also important, and a recommended privacy policy is attached to this document as an Appendix. This should include explicit support for inspecting personal data and data with personal implications, and the ‘right to be forgotten’. Support for these requirements is provided by the UOS platform.

Specifically, UOS data structures and APIs facilitate both relationship-based and specific attribution of relationships between objects, events, and people, and make it easy to inspect data held by user to enable data inspection as part of an open policy. Anonymization APIs are designed to enable irrevocable detachment of data from a user’s record, making it virtually impossible to reestablish data relationships even through inference, and yet still preserve the integrity of the data records.

Multinode

A key feature of the UOS Supervisory layer (otherwise known as UOS Core) is the multinode architecture. This enables the automated federation of UOS instances into an operational cluster which allows nodes to interoperate, sharing data, service calls and context, and enabling very scalable instances to be created. Multinode has a number of key features and capabilities:

As with other UOS features, multinode clusters can be managed from the easy-to-use admin UI, or

from the UOS Administrative API, or both. This symmetry of operation provides administrators with

simplicity of operation while maximizing flexibility, particularly when integrating UOS as part of a

deployed solution, or for a SI partner who wishes to standardize on certain 3rd party IT management

tools.



Multinode allows for the creation and extension of tiered hierarchies of node, and additional levels

can be created or added at any time. This provides significant flexibility and means that in practice

any cluster can grow without boundaries. UOS optimizes paths between nodes, so that more layers

does not have to mean slower responses. In most cases, UOS query processing is not significantly

slower in multinode clusters than single nodes, providing that network latency is not significant.

Even where networks impose greater latency, UOS clustering still works.

Multinode provides a number of tuning parameters to allow operators to optimize UOS

performance to suit load and deployment conditions. Replication allows for the automated

replication of data to other nodes, and does not have to be uniform across the cluster. This allows,

for example, nodes which have a heavy data receive burden to be freed from the task for query

processing or subscription matching. And if desired nodes can be somewhat specialized, for

example top level nodes may often play the role of Internet front end, and be configured with their

own multinode web service architecture with load balancing to equip them for this task, while other

nodes might be specialized towards business rules engine hosting.

Nodes can be federated at install time, or later in their operational lives when they already have

data. This means that in a deployment or construction sequence, individual nodes can initially run

autonomously, still providing benefits to their environments, but be connected together in a cluster

later on. One of the things this brings is the ability to build a city cluster progressively, starting with

individual buildings (“bottom-up”) or city data hubs (“top-down”) or even both, and yet still end up

with a holistic solution. Adding a node to a cluster need have no effect on users, devices, and

applications which were already connected to that node extracting value. It is only when it is desired

to make use of the extended data and control span that was created in joining the cluster that any

difference is noticeable.

As referenced earlier, nodes can be any combination of on-premise and cloud hosted. Additionally,

even nodes specialized to different deployment environments (such as Microsoft Azure and Amazon

Web Services) can be federated together. This makes the UOS a fully interoperable cross-platform

solution.

Network security and management does not need to be compromised to enable multinode.

Provided that each node has network visibility of its ‘parent’ and ‘child’ nodes in the node map, no

visibility of the rest of the cluster is required. This means that subnet partitioning and isolation can

still be used effectively, and that not all nodes need be equally open to, for example, the Internet.

UOS will perform inter-node routing efficiently to ensure that the application or RTC instance is

serviced via its ‘local node’.

Multinode supports other forms of flexibility in processing. For example with mobile sensors

inbound data traffic can be sent to any convenient node in a UOS cluster, with the data being

forwarded on to the sensors ‘home’ node. Multinode is also a key enabler for cross-node

redundancy, with its marshalling mechanisms supporting non-local peer data replication, and

failover reallocation of resources to a nearby node until the original node is recovered.

Multinode also supports flexibility in RDBMS deployment. While the modular model of one RDBMS

per node provides the ultimate in flexibility and distributed node support, for nodes clustered in a

similar environment (cloud, data center, campus fiber LAN) it is fully practical to use a RDBMS pool

design, which itself can have its own scale-out and redundancy architecture such as active-active



clustering. Upcoming releases will continue to increase optimization of RDBMS usage in this mode,

minimizing data marshalling and duplication where feasible.

As described earlier, multinode is a key enabler for hybrid architectures where a mix of on-premise and cloud deployment is used, and it is expected that the majority of UOS deployments will follow this pattern, even where hybridization is minimal; for example a small footprint of RTCs only where strictly necessary, to enable legacy device connectivity, or a primarily on-premise deployment still using cloud backup and/ or failover redundancy. There are a number of considerations in choosing the right deployment model, but in many cases this can be flexibly recast over time as needed. A separate document provides guidance in selecting the right UOS deployment model for your scenario as illustrated in the graphic below.

©2015 LIVING PLANIT - ALL RIGHTS RESERVED STRICTLY CONFIDENTAL

Building

Development

District

City

Platform Deployment Options

26PUBLIC BUILDINGS INFRASTRUCTUREURBAN SENSING PRIVATE HOMES

Local

Representative hybrid model

UOS

UOSUOS UOS UOS

UOSUOS

UOS

UOS

UOS UOSUOSUOS UOS UOS UOS

UOSUOS UOS UOSUOS UOS UOSUOS UOS

On-premise = Blue

In-cloud = Green

Analytics

Having provided the means to capture and store significant amounts of high quality history data, how is this leveraged to provide maximum value, to identify data patterns of significance to operators and providers, and to enable optimization of algorithms, services, and solution delivery?

The scope of ‘big data’ analytics is a complex and expanding field, with general purpose solutions competing with more focused and specialized solutions addressing the requirements of vertical domains. In order to provide the maximum flexibility for analytical functions, Living PlanIT primarily takes an interoperability-based approach, facilitating the integration with analytical functions provided by partners. We note that this is an area where major technology partners like to differentiate their solutions by adding value on top of the UOS platform, providing customers with extensive choice. An example is IBM Infosphere Big insights, which is capable of performing fast pattern matches across billions of records in under 4 seconds.

Our analytics strategy has 5 areas of focus:

Enabling accessible and flexible reporting and analytics on UOS data using Microsoft Excel and

PowerPivot. This delivers significant power to a mass audience including a large population of power

users;



Facilitating integration with partner and 3rd party analytics solutions including RDBMS-hosted

solutions through core UOS services;

Sophisticated next-generation pattern extraction and problem solving coming to market alongside

UOS with future releases;

Real-time analytics, enabled via tooling-based approaches and partner solutions;

Video analytics, both in-camera and offboard.

The following sections explore these different approaches.

Excel – an open window on UOS data

One of the observations we would make about how analytics get performed in the real world is that for a large number of companies, public sector entities, and users, a lot of it is either done in Excel, or a lot of what is done using more sophisticated software could be performed just as easily in Excel. To no small degree because of lack of data, the use of ‘big data’ and analytics is in practice somewhat less ambitious than the theoretical papers, marketing platforms, and demos would suggest. One of our ultimate aims with UOS is to solve the lack-of-data problem. Once we do that, we then need to similarly remove barriers of entry and improve velocity and democratize extracting insight and value from that data. That led us to making access to data via Excel a fundamental part of our analytics strategy.

The Excel template ships with the SDK, and handles some of the complexity of the UOS metamodel so that however your UOS instance is configured (including metadata extensions) you can easily create multi-dimensional cube views on the data and ‘slice and dice’ them as desired to extract invisible relationships and information and allow complex inspection of the data to take place, including the merging with external data assets as needed. And then you still have the power of Excel to be able to conduct what-if analysis, summarize and synthesize, and visualize information using built-in charting or 3rd party plug-ins if desired. All of this information is collaboration-friendly using the universe of Microsoft and partner solutions in this space, providing accessible ways to leverage this data.

With this tool, the entire scope of UOS data is available to you to inspect and analyze, bringing a lot of power in an easy-to-use and accessible format, with full support for the UOS security model.



Integration with Partner and 3rd Party Solutions

UOS supports 4 design patterns to drive partner and 3rd party analytical solutions:

On-demand access to UOS data store via APIs – Many analytical tools have out-of-the-box

support for oData, making integration with UOS very straightforward. This is particularly useful

in multinode cluster environments, where any number of UOS data stores can be accessed from

a single endpoint, with UOS marshalling all data required. In addition if a restricted view of the

data is required, this provides full support for the UOS security model.

Loading of external data warehouse or mart using UOS Data Management APIs – Again, this is

particularly useful in a clustered environment or where security policy-based filtering is desired.

This can also be achieved via direct RDBMS access and ETL tools, but this does not fully support

the UOS data model or multinode without additional work and is therefore not recommended.

Loading of external data warehouse or mart incrementally through subscription to relevant data

via the UOS API – This not only automatically maintains the data mart with optimum load

distribution, but also keeps near-real-time data available with historic data, and fully supports

the UOS security model and multinode clusters.

On-demand access to UOS data store at RDBMS level – This does require appropriate direct

access to the database engine and knowledge of/ drivers for the specific RDBMS used. This does

not fully support the UOS data model or multinode without additional work. It does have the

advantage of unlocking tools provided by the RDBMS vendor; for example Microsoft provides

SQL Reporting Services and Data Mining with SQL Server.

This provides ample flexibility to optimize solution architectures to requirements.

WISDOM (Advanced Analytics and Optimization)

Where “wicked” problems (Rittel & Webber 1973) that require exploratory data analyses of hyperspaces, or the optimization of many objectives (> 10) that tend to be incommensurable and conflicting in the real world, WISDOM (Chikumbo et al. 2015) can be brought to bear. The WISDOM acronym is derived from “Wicked problem Solutions through a transparent Decision making process involving many-objective Optimization and Multiple stakeholders” (Chikumbo et al. 2014). Wicked problems are notorious for being elusive when it comes to solving them, and even if a solution is found it only has a short shelf life, making it only possible to “tame” the problems. This is because wicked problems are characterized by complex interdependencies, multi-dimensional objectives and circular causality, i.e. incomplete, contradictory and changing requirements (Bettencourt & Brelsford 2015). As such WISDOM is a suite of tools that include:

Capability to construct “search spaces” from disparate data and simulation/ prediction models;

Heuristic search algorithms, in particular evolutionary algorithms for knowledge acquisition from

these search spaces in the form of Pareto fronts, which are sets of optimal/ near-optimal alternative

solutions;

Interactive visualization that engages different stakeholders in problem and solution formulation;

and

Multi-Criteria Decision-Making (MCDM) techniques collectively dubbed “decision-making by

shopping” that mimic eBay/ Amazon-like online shopping experience, where the products are the

knowledge acquired or alternative solutions, and the stakeholders are the shoppers driven by their

preferences and values.



Make the search space dynamic by continual updating via UOS and you have a suite of tools that can track/ tame the maddening circular causality characteristic. UOS-WISDOM is thus archetypical of an amplified mental process for solving a wicked problem, achieved by combining computational and strategic capabilities. The real world and the human strategic problem solving capability are separated by dimensionality, where the real world is practically a web of hyperspaces which humans are not very good at understanding. To apply the human strategic problem solving capability to world challenges we employ UOS-WISDOM to harness the brute force computational capability of computers and via sophisticated methods collapsing those real-world hyperspaces into lower-dimensional virtual spaces that can be comfortably explored and analyzed. The exploration mimics online shopping, where the user can search, compare, review alternative solutions, and add the preferred alternative solutions to “Cart” or “Wish List”.

WISDOM is a future extension to PlanIT UOS which is currently in development through the integration of 3rd party developed IP acquired by Living PlanIT. This enhances our out-of-the-box analytics and optimization capabilities, especially where complex and multi-dimensional problem spaces are involved, extending to include the class of NP-hard problems. WISDOM has been developed principally through collaboration between academia and industry in several institutions worldwide over a number of years, and has been successfully applied to problems as diverse as emergency response and land use management.

Real-Time Analytics

Sometimes known as ‘Stream’ analytics, this technique focusses on evaluating data as it comes into the system and producing insights in near-real-time for immediate exploitation.

There are a number of ways of implementing such capabilities in UOS:

Embedded code in PlanIT UOS RTC – this has the benefit of being extremely flexible and intercepts

inbound data at the earliest possible point. RTC has the capability to subscribe to and query

existing/historic data values from PlanIT UOS Core and can therefore fetch/ pre-fetch other data

which may be necessary to complete the analysis. May not require programming given the nature

of the development environment (see below).

Publish-Subscribe mechanism – this is already designed for fast response, high throughput,

scalability, and the ability to set up complex filtering algorithms. This means that results emerging

from pub-sub can be considered triggers for further action, and to represent insight.

Polling application solution – information is persisted rapidly in the UOS due to parallel processing

from the Urban Message Bus. Particularly if executed at a UOS leaf node (closest to the RTC layer)

this may be fast enough in many scenarios to provide sufficient support for near-real-time

processing and provides considerable flexibility.

Partner solution – a plug-in interface allows a number of our partners’ solutions to intercept data

coming through RTC nodes or across the Urban Message Bus and use this information in their real-

time analytics solutions.

A further category of real-time analytics is Video Analytics which is featured in the next section.

Video Analytics

Increasingly, video analytics is being used to replace certain classes of discrete sensing in the built environment. As the cost of cameras comes down and capabilities rise, this trend will increase. However video analytics carries a relatively high penalty cost in terms of processing power and potentially network bandwidth, and careful consideration to architecture and solution design are necessary to obtain maximum efficiency and performance from such solutions and to operate around real-world constraints.



It is worth noting that in many urban environments (public and private) extensive investments have been made in CCTV systems which in theory provide the video streams and infrastructure required to address this problem. However the vast majority of these were put in place with one requirement in mind (security) and the desire to maintain those operations combined with very conservative thinking and in some cases legacy architectures (analog) often impedes the ability to use such solutions as part of an IoT or Smart City system. Where significant redevelopment, refurbishment, or newbuild is taking place however, this is a prime opportunity to improve solutions.

It is not just ‘other’ solutions that benefit. Today’s CCTV systems are manifestly inefficient, relying only on the (unlikely) event of an operator having the right camera view on one of a small number of screens (relative to the number of cameras) at the right time. Yes the historic recorded video is still of use, but this does not guarantee real-time response. Widespread use of video analytics can help identify patterns which are worth highlighting to a human operator to make the final decision as to whether this is of interest or not. This can substantially improve ‘hit rates’ as well as helping ensure operator alertness. Combining such solutions with other data sources (microphones, end-user reporting, and customer flow analytics) can help provide additional context and help correct decisions being made in the operations room.

Video analytics can also be used for many other functions such as people counting and flow measurement, identification of lost or abandoned objects, identification of infrastructure damage, weather reporting, temperature measurement, identification of vehicles and persons, parking management (car parks and streets), traffic flow monitoring, and detection of possible loitering with intent.

In some solutions available today multiple forms of video analytics can be performed synchronously in the camera itself. This can provide advantages in terms of higher efficiency than relaying video back to a general purpose processor for analytics, and the ability to control network bandwidth to relay video imagery given that (barring analytics) full resolution/ frame rate video may not be required (in some cases the imagery may not be needed at all). A UOS video architecture is available as an application pattern which provides extremely high efficiency for video capture, backup, recoding, retrieval, analytics, and retro-analytics used with such systems.

Where cameras do not have built-in analytics, video analytics can be performed via a provided plug-in interface, either deployed close to cameras in appropriate hosts (such as RTC host environments) or collocated with UOS Core in a server room. Video analytics can also be implemented using Simulink libraries in the UOS RTC, and further partner solutions for this environment will be available soon.

It should be noted that in general we do not recommend cloud hosting for video analytics except where internet connectivity is extremely strong due to the need to carry multiple high resolution/ frame rate video streams across the wide area network.

RTC (Real-Time Control)

Unusually for products in this class, UOS provides a complete IoT architecture by providing not only the supervisory and data persistence layer, but also the real-time control layer foundation. This consists of a portable code container known as PlanIT UOS RTC. RTC is based on core software development which underpins the standard Electronic Control Unit (ECU) as used in Formula 1, Indy Car, and NASCAR amongst other formulae. Living PlanIT and specialized technology partners have a long-established co-development arrangement by which both organizations continue to develop and enhance the technology.

This solution currently uses MathWorks Simulink as a development environment and the entire solution (container and application code alike) is generated using that tool. This gives the solution a number of attractive properties:

Solutions can be developed without the need for advanced coding skills – control engineers can

define algorithms and models graphically which are compiled into working code;



Solutions can leverage any algorithm, code block, or facility from the MathWorks suite, including

MATLAB. This provides a wealth of functionality for the processing and analysis of data, and the

control of capital equipment;

No run-time license is required by MathWorks for the use of generated code, simplifying

deployment (note that RTC is licensed and uses a license management solution – see below);

MathWorks supports a very broad set of target operating systems (embedded, desktop, and server)

and processor platforms, allowing RTC to be implemented on a very wide range of hardware. An

operating system is not necessarily required provided that network stack and utilities are available.

This latter point of environment portability allows RTC to be integrated with existing controller architectures (as a ‘bridge’, future evolution, or functional extender) and deployed in a wide range of hardware hosts, becoming the foundation for a distributed intelligence infrastructure.

Additionally, Living PlanIT and our engineering partners have imbued the solution with further key properties:

The code container provides the environment for the consistent structuring of solutions which run

in parallel threads, monitoring and managing them as necessary;

The code container provides all code blocks needed for interaction with the PlanIT UOS Core;

Real-time control code can be implemented with latency as short as 10 nanoseconds (note: this is

a bare metal implementation using specialized communications – IP-based solutions will have

latencies minimally in the milliseconds range);

Applications running in the code container can be updated while they are running (within some

constraints);

The entire code container can be restarted in seconds;

RTC can be implemented as a very lightweight architecture;

Since the code container can be run in a desktop or server environment natively, it is easy to

simulate real-world deployments for real-time execution;

Solutions in RTC can be managed via APIs which are fully integrated with UOS Core, providing

centralized management and distributed execution;

Over 150 existing driver applications (adaptors) for legacy protocols and devices are supported out-

of-the-box and it is straightforward to build new or custom adaptors.

In the Living PlanIT architecture, the RTC code container is deployed in a number of hosts which typically run close to the sensor/ actuator networks with which they interact. Hosts can vary from dedicated hosts (either general purpose compact PC architecture or more specialized devices) to partner controllers which have been engineered to host RTC.

This allows RTC to provide the following roles:

Point of adaptation for heterogeneous sensors, especially where connectivity solutions vary;

Local point of control for data flows, including aggregation, scaling, and filtering;

Management of state of connected objects;

Local persistence (transient) to provide resilience where connections to UOS Core are interrupted;

Point of adaptation for controlled capital equipment, providing actuation host;



Enabling environment for autonomous real-time control functions;

Integration point for sourcing of information from UOS Core for use in local control and data

management operations;

Prioritization-and-buffering engine to help ensure that data in most immediate demand flows

efficiently;

Source of redundancy by enabling redirection of payloads from one RTC host to another in the event

of failure (this is particularly relevant where payloads are similar, for example between floors in an

apartment building).

Modeling Services

UOS Modeling Services are in development – Living PlanIT and selected partners in the CAD/BIM space are building extensions to the UOS platform to exploit synergies between design-time and run-time activities in the built environment. Specifically this will:

Improve capabilities for referencing and reusing design model features and data in an operational

context, including visualization and geo-encoding;

Simplify the designing in and manufacturing of IoT networks into a physical space;

Simplify the commissioning and operation of IoT networks and the related physical structures;

Improve planning of maintenance operations by combining knowledge about optimized

maintenance schedules (predictive) with precise costs and timings for access with minimal collateral

damage;

Improve physical designs of buildings iteration-over-iteration by allowing representative real-world

data captured from prior designs to be used to simulate and optimize the non-soft elements of the

next building (taking into account the ability of algorithms to be themselves enhanced during the

operational cycle).

Information Traceability and Rights Management

PlanIT Crumbs is the cryptographic and encryption technology invented by Living PlanIT that embeds digital water marks and tags in data generated from sensing and control systems that relate to biological or systems activity. This is currently in development for release in a future version of the PlanIT UOS and will further enhance our capabilities in the areas of privacy and security through enhancing data traceability. Combined with rights management solutions it becomes feasible to manage record sets and information which results from historic (authorized at the time) access to UOS stored data which nonetheless becomes a liability, threat, or concern at a later time.



PlanIT UOS Capabilities Summary

Integration – a highly portable real-time control and driver/ adapter layer, over 150 in-box standard

protocols and common proprietary formats, integration flexibility for common data feed paradigms

and integration with ERP, support for video analytics with plug-in support for simulation and further

specialized analytics suites in development.

Open Access – PlanIT UOS API is enabled entirely by open, cross-platform standards including oData

(Open Data Access), OpenID, Oauth and ODRL. UOS REST-based APIs are tested against multiple

platforms to ensure interoperability. PlanIT UOS also provides support for the HyperCat content

publishing standard. UOS enables platform metering for all calls and result sets in order to track

usage or form the basis for data-based billing. The PlanIT UOS API has 3 classes – core APIs delivering

mainstream UOS functions, application APIs providing an application hosting platform for

convenience, and functional APIs which provide a common way of requesting equivalent

functionality from different makes and models of equipment which perform the same function.

Real-Time Optimized – PlanIT UOS is designed for real-time, from the RTC layer which provides

model-driven programming using industry standard tooling (MATLAB/ Simulink) through high-

compression data transfer protocols through a distributed service bus implementation through

high-performance filtering publish and subscribe functions which use oData as their filtering query

language. Filtering is applied as close as is feasible to the source minimizing wasted network traffic.

This highly functional pub-sub engine also enables data-driven solutions and the rapid propagation

of the right data to the right endpoint in the right timeframe.

Scalability – PlanIT UOS is designed to scale down to controlling a single function on a very simple

controller (e.g. Raspberry Pi) and all the way up to massively complex systems. Single node

multiprocessor implementations can handle millions of endpoints, while multinode automates the

building of federated networks of UOS nodes for ultimate scale. The UOS authorization model is

based on declarative security policy statements, enabling partial automation of security policy

definition from contract definition systems but more importantly a scalable approach to securing

private data based on context vs explicitly granted permissions.

Data Alignment – PlanIT UOS data model has been designed to enforce coherent data stores

minimizing the need for post-hoc data cleansing and alignment actions. While doing this, UOS can

take on the widest possible sets of sensor, actuator, mobile device, and user information. A

canonical model is shipping in the box, but implementations can be extensively customized at the

possible expense of cross-deployment application interoperability.

Ease of Application Development/ Integration (PlaceApps) – open APIs, conceptually simple and

consistent REST interfaces, aligned data and powerful features make PlanIT UOS a quick and

effective platform for developers to integrate with or develop against.

Rich Integration with Physical Models (CAD/ BIM) – PlanIT UOS Model Services will enable close

coupling between CAD/ BIM models and UOS, extending UOS support to design and manufacturing

of the built environment as well as operations. Plug-ins for common CAD systems will facilitate two-

way integration, simplifying UOS configuration and deployment and making UOS-managed data on

real-world physical activity available to designers and simulation suites, enabling development-to-

development optimization before any hard points are established.



Product not Asset – PlanIT UOS is a product and as such enables a mass market for equipment

integration, applications, and solutions to develop, with portability between implementations and

territories. A growing ecosystem of partners already exploits UOS in its products, solutions, and

services.

Low cost, high return – use of standard platforms and components and a 100% software-based

approach makes PlanIT UOS cheaper to deploy than traditional urban control solutions, while the

coherent data and controls platform drives reuse of sensors, controllers, and information, yielding

the economic delivery of larger solution sets as well as the ongoing optimization of built

environments. UOS equipped buildings will get cheaper to run over their first few years of operation

– not more expensive as is classically the case.

Deployment Models

Why Cloud Deployment?

Over the past years, the design paradigm for the supervisory and data management layer for the Internet of Things (IoT) has shifted significantly towards multi-tenant, service-orientated cloud offerings and consolidated somewhat in that form. The reasons for this are manifold, but include the following:

Cloud infrastructure providers present highly reliable infrastructure that is cost-effective to

maintain. This contrasts with relatively high investment costs for redundant local infrastructure;

Most IoT projects are still small, and therefore do not necessarily justify an investment in discrete

infrastructure;

Starting small in particular is substantially assisted by a pay-as-you-go, zero CAPEX model;

Where a business case can be made, usually this involves offsets or reductions in OPEX, which are

easier to reconcile with costs which are also presented as OPEX (no additional budgets required, no

need for medium-term planning and rate-of-return calculations);

Many locations are challenged to find appropriate spaces for on-premise infrastructure;

Local data centers are not always found where needed, and do not offer either the connectivity, or

the service needed to provide resilient and flexible infrastructure;

Local hosting partners often have models which do not support progressive deployment when

needed, or the flexibility to scale up and down as required with demand;

Aggregation of payloads across multiple customers helps to smooth demand and get around the

challenge (even with some cloud environments) of quanta, as another virtual machine needs to be

spun up and paid for;

Aggregation of payloads allows economies of scale to be exercised in terms of forward

commitments and forward buys of hosting/ cloud capacity for improved economics;

Much of the current focus of IoT is currently orientated towards cloud environments which support

devices that can provide data and/ or be controlled. While this is an incomplete architecture to

address all IoT and Smart City requirements, it does represent “low hanging fruit” and the majority

of use cases being explored right now. In this model there is little point in trying to exploit any local

affinity to on-premise hosting;



A significant proportion of the device market still uses network solutions that are wide-area or do

not provide open local endpoints. This includes both devices which connect via cellular networks

and those which are designed to communicate with smart meters using ZigBee. These devices do

not expect or look to benefit from presence of a broader set of local entities;

Big Data Analytics – as opposed to Real-Time Analytics, big data analysis is easier to perform in a

cloud environment with flexible infrastructure and the ability to collate large data sets and use a

wide range of available analytics solutions.

Why On-Premise Deployment?

The justification for on-premise deployment breaks down into two subcategories: on-premise deployment for real-time control and device adaptation; and on-premise deployment for supervisory functions. Neither case is entirely orthogonal to cloud deployment – indeed we will demonstrate that on-premise RTC provides an extremely rational adjunct to cloud deployment of the supervisory layer, and can only really be avoided where sensors and actuators are sufficiently sophisticated to communicate directly and reliably using well-understood IP based protocols directly with cloud assets, where extremely reliable internet connectivity exists, and where latencies of the order of seconds can be tolerated. This is highly unusual in the real world.

On-premise supervisory functions tend to be more of an alternative to cloud, although again network availability and performance is a factor, and hybrid architectures offer a lot, especially given the ability of UOS Multinode to span the entire construct.

Why On-Premise RTC Deployment?

There are three principal drivers:

Heterogeneity

The world of devices continues to be highly heterogeneous in terms of hardware and software architecture, processing power, storage, network capabilities, and connectivity paradigms. This makes a generalized solution for how to send data to a cloud-based service difficult to establish.

In theory we are trying to address here the challenge of connecting anything from a current-based sensor through to a rich and sophisticated embedded or portable device to the same cloud environment through a patchwork of networks, without having to force the characteristics of the local architecture into the cloud environment, or burden the cloud environment with a massive combinatorial space of adaptation, or remain with a non-coherent data model when the goal is to increase coherence and therefore insight at that level.

It will rapidly be seen that a generalized adaptation architecture is needed which has the following layers (not all of which are required in every case):

1. Device Connectivity

2. Protocol Support and Adaptation

3. Data and Metadata/ Enumeration Adaptation

4. Data Caching/ Temporary Storage

5. Data Transformation and Filtering

6. Data Analytics/ Eventing/ Prioritization

7. Data Format Packing and Encryption (where needed)

8. Actuation Listener and Manager

9. Support for Localized Host Device Code

10. Local Device Code



While there are a number of approaches to providing such facilities to end nodes of an IoT solution, Living PlanIT has chosen the portable code container approach as representing the most flexible and efficient path for enabling such features. As will be seen, such an approach and architecture also provides support for the next two drivers.

Locality

As discussed earlier, while device-to-cloud is a common paradigm, it is not the only paradigm which applies to the Internet of Things/ Smart City space. In most sophisticated environments (such as urban infrastructure, the interior of a building, or an automobile) there are a number of different sensors (including sensor devices), and there are potentially a number of controllable assets (generically called actuators), and at least one controller device. This provides opportunities for increased efficiency in servicing the sensing/ actuation environment, and opens the door for autonomous local interactions which can happen in real-time as opposed to internet speeds.

Shared connectivity solutions are typically arranged via use of a converged IP network infrastructure, which is becoming an increasingly well-established pattern, and again provides efficacy in establishing connectivity to other parts of the environment, the cloud, or the Internet. Such patterns drive the use of shared adaptation/ control nodes deployed as part of a shared sensor/ control network architecture. Such nodes will vary significantly in form and characteristics, but can be managed using the same battery of approaches described in the prior section. The portable code container approach does have the advantage of efficiently serving multiple requirements flexibly, while maintaining consistency from a perspective of function, manageability, and interface characteristics.

This paradigm also opens the possibility for the supervisory and data persistence layer to be hosted in the locality, particularly if many application/ client demands are also localized. This does not preclude higher-level interactions or aggregation in the cloud in hybrid architectures; there are a considerable number of possible configurations. Again, while the cloud has great advantages, exercising local affinity to some degree can bring considerable efficiency and resilience, and is particularly relevant when replacing historic building management or industrial control solutions with more flexible, shared, general purpose open IoT infrastructure.

Such an approach also insulates the solution architecture from dependence on a highly available and reliable internet connection. In many parts of the world this cannot be obtained at all, and even in more developed scenarios may incur costs which are more readily offset by on-premise RTC or even UOS Core architectures.

Legacy

In sophisticated and scale Smart City/ IoT deployments, which are not 100% new-build, legacy devices will be encountered. Even in a new-build environment, politics, legislation (especially for safety critical systems) and conventional thinking may bring in traditional vertical control environments. Many of these systems will use non-ICT networks, transports, protocols, and data formats and it is not unusual for these to be proprietary and not readily available/ supported by their makers in a heterogeneous environment. As such, having access to drivers which have been developed to work with such legacy systems is critical, and being able to deploy and manage these flexibly to be able to work around connectivity limitations in particular is a key requirement. In many cases an intermediary device providing protocol conversion is an absolute necessity and it often will not easily be possible to add new code or capabilities to a legacy device even if interoperability with modern network types can be enabled.

Such intermediary devices tend towards architectures similar to those discussed in the previous section. Whether such devices are deployed purely as legacy gateways, combined with support for new sensors and new subsystems, or integrated with vertical market controllers with a more extensible architecture is a decision for architects and installers.

Why On-premise Core Deployment?

Four considerations drive on-premise deployment:



Local Processing

One of the largest drivers for an on-premise architecture is the need for local processing. Certain use cases drive this more than others. As an example, applications which make heavy use of video are likely to find cloud-based architectures suboptimal due to the high bandwidth requirements to marshal multiple video streams offsite, and then back to site in case of demand. An in-cloud controlled architecture with local storage only can obviate this if simple record-and playback is needed (CCTV) but increasingly cameras play an integrated role as part of IoT architectures, with various video analytics routines turning them into effective multi-functional smart sensors.

Where these analytics are embedded in the camera or provided by a dedicated host (such as an RTC host) then this still might not require on-premise server-level hardware, but once such facilities are applied at the aggregate level (i.e. deriving near-real-time inferences from processing data of multiple cameras) the case to move this workload to the cloud becomes increasingly tenuous.

Hybrid architectures can still be used (such as video processing carried out more locally but more general data being managed in the cloud) but not all core platforms readily support such complex architecture, and simplicity may well argue in these cases for an on-premise solution, at least for the first layer of processing. This does not preclude higher levels of aggregation and analytics (or even simply backup) being delegated to the cloud.

Application Demand

In some cases, the demand for the particular applications being served by the platform can also be mostly local. Take for example a smart retail mall solution where the client activity consists either of ‘back office’ desktops for center marketing and management personnel and retail branch managers and employees, or smart device applications where devices are connected principally through a center-provided and managed free Wi-Fi service. While all of this interoperates with the internet, and can source external data feeds or enable retailer head office access accordingly, the majority of the data is generated and consumed locally. Another such case involves embedded infrastructure in an apartment building, where the ‘in-walls’ nature of a lot of the transactions dictates a concentration of locality. This affinity effect ultimately can drive the selection of on-premise processing simply as a means of reducing network costs and improving performance through the eradication of latency; although again, it should be noted that mission-critical functions are likely to be concentrated in the already-distributed RTC layer.

Resilience

We are sure that the immediate reaction of most ICT professionals is to declare properly-hosted cloud infrastructures generally more resilient than a local platform, and measured in terms of server uptime, one would have to say this is likely. Particularly if non-redundant local architecture is used (not recommended) the probability of equipment failure is greater, and the ability to orchestrate prompt recovery (especially remotely) is materially less.

However in some parts of the world reliable wide-area network infrastructure is relatively hard to provision, and in these conditions the greatest risk of failure changes from equipment failure to a failure to communicate with the outside world, and the cloud. Additionally for high-risk situations such as a security system an attack may commence with a relatively straightforward disruption (based on wire or fiber cutting) to external communications as a prelude to more intrusive access. Particularly if local support is available (for example an existing machine room or data center), and/ or where redundant host equipment is installed, in some cases local implementation is the best path for resilience.

This can be enhanced in a scaled local development, for example clusters of several large buildings. A building might justify a server node on its own merits, but this can then be cross-coupled with an adjacent building, where in the event of failure, critical workloads (especially if similar) are transferred to the adjacent site. Coupled with locally redundant hardware and redundant design of network infrastructure and real-time control layer, a highly resilient system can be delivered economically. A larger cluster brings even more benefits as it may be sufficiently geographically dispersed to allow backup data to be marshalled from one node to a further-flung one as an alternative to cloud backup.



Security

While we do not subscribe to the belief (often practiced by plant floor systems providers) that old, not-well-maintained infrastructure which is not connected to the internet is inherently secure, it is equally clear that certain attack vectors can be usefully minimized by limiting external exposure. While this introduces challenges in terms of maintenance and support, the UOS has been designed in terms of license management, support, and update capabilities to support this scenario as well as the more normal connected-everywhere scenario. Even in the case of isolation, consistency in terms of data models, application patterns, and APIs is still of value particularly from a perspective of application portability, and also protecting against the case that one day the solution might be joined up to a higher order one (e.g. building cluster or city), and/or data exported out-of-band for aggregation with some other analytical solution.

We promote to our customers and partners that good infrastructure, platform, and application security coupled with strong design and sensible security and privacy policy is the best defensible position for IOT solutions, but some clients will inevitably insist on an isolated or semi-isolated solution which nonetheless seeks to leverage the advantage of a consistent platform and some level of participation in the broader ecosystem.

Why Hybrid Deployments?

The UOS Multinode architecture was designed to address multiple, non-exclusive use cases:

Scale out without architectural limitation in either cloud or on-premise environments;

Ability to implement ‘tiers’ of data and controls management which mirror physical properties (e.g.

building-cluster-district-city-state);

Support for on-premise implementation where colocation of hosting facilities is not an option, or

non-optimal for other reasons (see above).

This third point also informs the use of hybrid architectures. If there are (for some scenario) local affinity reasons which merit local hosting, the value of these reasons decays as the level of aggregation increases, because the mean distance from end node to hosting facility inevitably increases. From an architectural perspective, if I am in a building-cluster-city model, whether the city server is at city hall or in a cloud facility ‘somewhere’ is of little relevance to most people, who if they have local affinity benefits will be getting them from their local server, and if they do not, will be accessing via the internet in any case.

Therefore it is likely that hybrid architectures will be preferred for many scaled deployments, and indeed this architecture is used for our well-known airport project in order to provide support for extensive off-camera video processing, while the majority of UOS functionality is cloud-hosted in order to avoid physical space constraints in the airport data center.

Another hybrid pattern is the use of cloud facilities for various levels of redundancy. In some cases this will exist purely of an infrastructure level data backup, in others a live, replicated UOS instance, in yet others a full replication of a solution stack (including application services) held in hot or warm standby ready for application in the event of onsite system failure (assuming that this failure does not extend to internet connectivity). The choice is between the customer and the solution architect, and varies according to Service Level Agreement (SLA) requirements and solution constraints.

Hardware/ Host Strategy

Overall PlanIT UOS Hardware Strategy is based on the following goals:

Enable optimized and appropriate hardware host support through software features;



Support an extremely heterogeneous real-world sensor and controls environment that we cannot

entirely control;

Provide optimized hardware architectures where clients want a complete solution from us and our

partners (especially in new build);

Provide client choice in hardware selection and avoid dictating answers;

Make sensors and embedded systems (whatever their origins) part of a holistic software based

infrastructure;

Push intelligence and features as far out towards the edge or the ‘cloud of things’ as possible;

Provide secure, UOS-managed interactions as close to the edge as possible;

Enable highly flexible, managed distributed intelligence, performing tasks where it makes most

sense to perform them (especially filtering, normalization, aggregation, and triggering of simple

logic);

Create the most coherent, cohesive and efficient network of devices and hosts possible and

maximize quality of insight and control across as broad a spectrum as is feasible.

Our primary strategy for PlanIT UOS RTC hosting is to ensure widespread adoption by our partner community and embed RTC in a wide range of controller architectures, enabling a multi-tier distributed intelligence environment where functions can be relocated to the most logical place to perform them, often relieving load on higher-tier processors and enabling improved performance at lower cost.

However to serve our current customer and partner base and the needs of many existing deployments a second strategy is to ensure that a first class set of hosts with differing form factors is available to meet needs.

Our first of a family of products along these lines is currently being designed in collaboration with the highest quality manufacturing partners. This leverages our strategic partners’ long experience in building robust hardware, and will use automotive grade components in order to provide enhanced operational windows and longevity, while also taking advantage of economies of scale.

This solution is intended to be a primary RTC host and has capacity to support an extensive (hundreds of devices) IoT network with multiple concurrent applications. For maximum flexibility and compatibility with the built environment this solution is based on Microsoft Windows Embedded, and will leverage Intel processors.

Key differentiators for this solution include:

Enclosure capable of being installed in hostile environments;

Secondary monitoring processor capable of restarting the mainboard in the event of detected

lockup or critical failure;

Modular support for multiple types of network/ connectivity solutions to IP networks as well as

sensor networks ranging from ZigBee to A-D connections and relay ports.

Branding for this device is still in development.

Concepts for other devices (including modular sensor network gateway and bridge devices) are under development with our strategic partners and other hardware specialists. This includes an on-premise low maintenance PlanIT UOS Core host based on a Branch Office Box design, and an in-vehicle device, leveraging not only the expertise of our partners, but also Living PlanIT’s own in-house ‘connected car’ domain IP acquired in 2010.



Interfaces and Protocols

Overview

PlanIT Urban Operating System is intended to provide the platform for smart city development and deployment and leverage IoT/ M2M-capable devices. As such, it is critically important to strongly interoperate with a wide range of devices, protocols and other platforms. The PlanIT UOS has been designed to “rationally maximize” this through the following principles:

Completely open, platform-neutral access to all core UOS interfaces;

No “private interfaces” accessible only to Living PlanIT or “favored” partners/ customers;

Support for key industry standard protocols where these have significant traction/ take-up and do

not overly bias the platform towards any particular subsector of the market;

Use of established industry standard protocols and interfaces where possible and practical;

Use of emerging industry standards where established standards do not exist, and where possible

and practical;

Use of Living PlanIT-created protocols where effective standards do not exist, making these openly

published and available to the market, and supporting adoption by standards bodies when

appropriate (based on traction);

While adhering to the above, avoiding the traditional pitfalls of being a “universal adaptor” through

ensuring lightweight footprint and strong performance at scale.

This document describes each of the interfaces that are expressed by the PlanIT UOS and the current plan for the architecture of these interfaces and what protocols/data formats are supported. It should be noted that not all features listed may be available in all versions of the product, and may not yet be supported in current available versions. The final section of the document contains further details on the Living PlanIT philosophy with regard to open-specification or open-protocol solutions and how these differ from the commonly-requested open-source approach.

PlanIT UOS Architecture

In order to comprehend the role and rationale for PlanIT UOS interfaces, some understanding of the UOS architecture as explained and depicted earlier in this document is necessary.

API (Application Program Interface)

The PlanIT UOS API is designed to be the most commonly used interface, as it is fully expected that more entities will write applications for the platform than will integrate existing platforms or data feeds, or integrate sensors or assets requiring actuation. The API consists entirely of web services delivered over IP-based networks, and may reasonably be described as a pre-built Services Oriented Architecture (SOA). Living PlanIT recommends use of SOA architectures in designing and deploying applications on the UOS platform.

UOS uses the Open Data Protocol or oData as its query mechanism for data retrieval and the intrinsic filtering of subscribed data. This is implemented on top of the UOS Data Model, which is described in the PlanIT UOS Data Model Specification and the PlanIT UOS Software Development Kit (SDK).



Currently all UOS API calls are expressed as RESTian web services, with JSON data binding. The UOS technically provides support for http and https but http is disabled except by specific arrangement in order to avoid the accidental exposure of non-secure interfaces. See PlanIT UOS Security Model documentation for more details.

The PlanIT UOS API is divided into 3 functional classes:

Core APIs – these provide access to the main PlanIT UOS Core services including data access,

message bus, publish-subscribe system, built-in analytics and simulation support, security and

identity model, and management and monitoring functions.

Application Support APIs – these provide services that facilitate the hosting of applications directly

on the PlanIT UOS Compute Platform. If these services did not exist, applications with server content

leveraging the UOS would always require at least two platforms: the UOS instance; and a separate

hosting environment. While this deployment model is always inherently supported, in many cases

it will be more convenient to host on the UOS platform. Example APIs include notification services,

application-local persistence, and application service deployment. It should be noted that delivery

of class 2 APIs generally lags classes 1 and 3 because it is not strictly necessary for UOS deployment

or usage.

Functional APIs – these abstract and normalize capabilities provided by actuate-able capital

equipment interfaced with the UOS. For example, multiple families of luminaire/ controller from

multiple lighting providers can be controlled by the same API without the application developer ever

needing to care what type of equipment he is controlling.

DSI (Distributed Scale Interface)

The PlanIT UOS DSI (Distributed Scale Interface) supports the interaction of the two core UOS layers (the controls layer and supervisory layer) and also enables the distribution of functionality across multiple instances of UOS Core, providing extensible flexibility in how the UOS is deployed and the ability of UOS to scale to an extremely large scope. While this interface is conceived principally as an ‘internal’ interface to support the operation of the UOS it is not private. Opening up this interface brings the following benefits:

Flexibility of deployment especially in IoT scenarios – devices may not need the services of the

controls layer and may be able to interface with the supervisory layer directly;

Partners and integrators can use the UOS supervisory Layer with legacy controllers or their own DSI-

compliant controls architecture;

Partners and integrators can use the UOS controls Layer with no supervisory layer or with an

alternative supervisory layer (not recommended, but feasible).

Both the UOS controls layer and supervisory layer require the DSI to be networked using IP, although the use of bridging technologies in-between that are sufficiently performant and transparent cannot be ruled out.

The DSI has two transport solutions which are used for differing purposes. Generally both need to be implemented for full DSI support. These are:

RESTian web services interface (https): used for low volume sensor data, high priority traffic from

the controls layer, and for command and control purposes;

Websockets interface (TCP/ IP): used for message bus/ high volume sensor data/ bulk movement of

time series information and also for persistent communications with mobile platforms.



For the supervisory layer, the RESTian interface supports an API to send sensor data to the UOS using the Living PlanIT TSP (Trivial Sensor Protocol) format. Additional calls include calls used in coordinating UOS supervisory layer Multinode behavior and the management and monitoring interfaces for UOS Core.

For the controls layer, the RESTian interface supports an API to send control instructions from the UOS API to controllable assets connected to an instance of the PlanIT UOS RTC (controls layer host). Additional calls include the configuration of the UOS helper application and the RTC piece of the management and monitoring interface is also implemented.

The websockets interface supports the high speed message bus used to transport data matching the pub-sub mechanism and also the bulk sending of sensor data using the Living PlanIT SDP (Sensor Data Protocol) format.

For inter-layer and inter-node use, Living PlanIT provides two optimized data formats which correspond to the UOS Data Model. The TSP is intended to make integration with UOS very simple and is optimized for low frequency data updates. This format is already published by Living PlanIT and is available under a free license.

For efficient high bandwidth communications of multiple sensor streams, the Sensor Data Protocol (SDP) should be used. This format uses multiple forms of compression and can handle significant variance in multiple concatenated streams optimized for hundreds of individual sensors per stream. SDP is out of necessity more complex than TSP but will also be published by Living PlanIT under a free license in order to facilitate its use in aggregators or by 3rd party controller manufacturers.

SCI (Sensor & Controls Interface)

The PlanIT UOS SCI provides the means by which sensors and actuators are integrated with the UOS. Integration occurs in three ways:

The use of a standard protocol (TSP, SDP, or other supported protocol – see below);

The use of an existing “driver application”;

The development of a new driver application.

In addition the SCI also provides the point of control for downstream devices (aggregators, smart sensor boards) which provide UOS-supported management, monitoring, and security interfaces through hosting of the RTC. This will be described in a separate document.

This interface is designed to use IP-based networking. Other types of network must be adapted to IP using downstream gateway devices or host-provided adapters with OS-level drivers.

Standard Protocols

Standard protocols supported include the following:

Living PlanIT Sensor Data Protocol (SDP) and Trivial Sensor Protocol (TSP)

Modbus (RTU and TCP)

OPC (DA/AE)

X10

TAPI

SMTP

SNMP

SNPP



DDE

Others will be added based on market penetration and partner request.

Adaptable Transports

The ‘native’ transport for the SCI is IP-based networking (mostly TCP/ IP, although UDP/ IP is also supported). All current environments that Living PlanIT supports can handle both IPv6 and IPv4 depending on customer requirements, with IPv6 being recommended in order to avoid address availability issues.

In addition the aggregator layer enables other networks and transports to be adapted to IP for use with the UOS. A non-exhaustive list of such transports follows:

Current-based sensing devices (via A-D conversion)

Serial Port

USB

ZigBee, 6LoWPan, and other 802.15.4-based networks

Z-Wave, EnOcean and other non-802.15.4 mesh networks

Wi-Fi (802.11x)

Wireless Cellular Networks (3G/4G/+)

Modbus (serial forms)

BACnet

LonWorks

Existing Drivers/ Legacy Systems

These drivers are developed by Living PlanIT and its partners as new equipment is interfaced with the UOS. New drivers are being continually certified and made available. Below is a sample of existing certified drivers (non-exhaustive list):

Lighting Systems:

o Philips Dynalite

o Philips ColorKinetics

o Philips Outdoor

Fire Panels:

o Android

o Detectomat

o Eltek (eComm protocol)

o Esser 5008, 8000

o Gent 3400

o Hochiki

o Howfire



o Kentec

o Kidde Vega, Proceyon

o Multi Alarm IFAX

o Notifier ID50, ID1000, Morley, AFP4000

o Protec AN95, 5400, 6400

o Schrack Integral N3 and Maxima

o Siemens Cerberus Algorex, CZ10

o Thorn Minerva

o Trident

o Wormold

PA, Audio, and TAPI systems:

o Audionics Audio Router

o Cisco Call Manager

o Complus Teltronic Intercom GE100, GE200, GE700

o ComTalk PA system

o Ericsson MD110 (TAPI)

o Mitel 33

o Vortex VX

CCTV systems:

o American Dynamics Micro Power EP Switching Matrix

o American Dynamics Intellex

o Avigilon

o Axis encoders, decoders and IP cameras

o Barco Hydra video display

o Baxall 7000 matrix, ZMX, ZT6 matrix, Pyramid;

o BDL UVSS

o Burle/Philips/Bosch Allegiant LTC8000 series matrix

o City Sync ANPR

o COE telecommand

o Dahua DVR

o Dallmeier encoders, decoders and DVRs

o Dedicated Micros DVST, Uniplex Series 2, Unicord

o Drax 17 Duplex Multiplexer



o Ernitec Matrix Series (ELP)

o Geutebruck VICros III matrix

o Hikvision DVRs

o Honeywell/ Maxpro MAX-1000

o Ipsotek IP Series IPS: IPS-4, IPS-10, IPS-16

o ISolutions IRecord 5000 video system

o JVC SR-S970EK VCR

o March Networks

o Meyertech ZoneVu II video matrix

o Mitsubishi HS-S5600(BRS) VCR

o Molynx Visilynx matrix, TTX309 interface to 600 series matrix

o NiceVision video system

o Panasonic AG-7630, AG-6040, AG-6760 VCRs, WJ-SX550 Matrix

o Pelco Endura or DX8x00 via X-Portal XMI

o Philips matrix

o Photon Surcha telemetry receiver

o Photoscan dimension matrix

o Plettac POSA video system

o Plettac VAZ300 matrix

o Synectics X250M series matrix

o Vicon Kollector on Vicon NET (limited functionality)

o Vicon Nova 1500 matrix system, VPS series

o Vision Factory Montage Multiplexer

o Vision Systems Adpro VST10 Fastscan

BMS/BEMS controllers:

o Allen Martin energy management system ACM

o American Automatrix Public Host Protocol (PHP)

o Andover Infinity, CX and CMX controllers via CLS

o Andover Netmaster and AC8 controllers

o AutoMeter IC500, IC700 and C-Matic 3300 ACM

o Cisco Network Building Mediator (Richards Zeta)

o Johnson Controls IU-9000 interface to N2 network

o Leibert 9000 UPS



o Manas energy meters database

o Mitsubishi FX series PLCs

o Next NCS2000

o Nudam ND-6050, ND-6053, ND-60xx

o Optimal energy and SCADA database

o Polaron Light link 98 system

o SAIA PLCs via S BUS protocol

o Sauter printer port

o Staefa Nico PLC

o Stark EMS

o Tour and Anderson Sys7

o Trend Control Systems Trend IQ

Security systems

o BDL UVSS

o Bold Communications RX2000 Alarm Receiver

o BT Redcare

o Casi Rusco Picture Perfect access control system

o City Sync ANPR

o DSS200 Nurse Call System

o Europlex intruder panels

o Fermax door entry system

o Honeywell Galaxy, Series 3, Classic, Dimension

o Marconi SMS

o Menvier intruder panel

o Morse Watchmans Keywatcher key management system

o Northern WinPak access control system

o Scancom Scantronic intruder panels

o Shop Alert system

o Smiths Detection Explosive Particle Detection system (EPD)

o Software House C CURE 800 access control system

o Solid Card RiTA access control system

o DSI Ultra Guard ACU (events only)

Messaging Paging systems



o Multi Tone Access 300 MIT system

o Nevotek Nevotek IPTV system

o Nokia 30 GSM connectivity terminal

o Scope paging system

o Textforce SMS service

People Counting Systems

o Experian Footfall

o Crowd Vision

Car Park systems

o Dambach PGS

o Erben Control Systems Database

I/O modules

o Advantech Data Acquisition Modules

o Audon Electronics SOM1 Serial Output Module, SPO-RL8 4 Relay Output Module

New Drivers

Living PlanIT partners can develop their own driver applications using the UOS SDK and appropriate tooling. Developing a custom driver allows for any arbitrary ID convention, multi-sensor concatenation, data format or variance to be supported for sensors, and is typically required for actuators in order to expose functionality provided by the equipment (although a general purpose actuator driver is in development). The UOS SDK provides more information on how to develop a custom driver.

EAI (External Asset Interface) – Deprecated in Release 4

The UOS EAI was originally designed to provide a generalized integration server capability in order to support the integration and alignment of external data sources and complex integration with other external assets such as ERP and billing solutions. However with the implementation of the Business Rules Framework in release 4 of UOS, the EAI as a separate interface was deprecated in favor of providing the same support via the UOS API and the Business Rules Engine (BRE). The BRE allows for on-event invocation using subscriptions, invocation via API call, and invocation via scheduler, and supports MDA-driven code development of arbitrary complexity, including the XSLT and custom code options available in the former EAI. As such, this is now the preferred near-real-time plug-in interface for UOS.

More complex integration scenarios can be optionally supported using integration server products such as Microsoft BizTalk Server or IBM WebSphere which can be co-deployed with selected UOS supervisory layer nodes. This allows all of the adapters and sophisticated messaging and orchestration functionality supported by such products to be used to adapt external functionality to the UOS Message Bus, Data Model, Data Store and API.

As an alternative to the integration methods described here, customers can integrate their own high-level, low-speed generalized service bus with Living PlanIT’s Urban Service Bus by making use of our core API.



Open Specification Philosophy

Innovation and Open Standards

Innovation in the technology sector generally consists of leaders developing from time to time new concepts which are implemented in software, firmware and hardware that significantly advance an area or areas of technologies. These innovations can through mass adoption become de facto standards and many ultimately are at least in part canonicalized as de jure standards through recognized international standards bodies. Typically the lag time from proprietary implementation through to agreement on an international standard is many years, with 5-10 years not being uncommon once implementation patterns are established for a vertical or sector.

For customers to reap the benefit of these technologies during this period requires careful selection of a vendor who is pragmatic about leading, supporting, and adopting standards. Excess effort in trying to provide a ‘universal adaptor’ or participate too early in too many standards activities (which may be competitive) usually results in a lack of effective implementation and velocity, to the customer’s detriment. Equally a hidebound or extremely proprietary mindset may provide short term benefit for long term pain as the cost of inflexibility is brought to bear.

Living PlanIT is committed to support:

Key standards that are mature, stable, and adopted by relevant industry sectors;

Adoption of Living PlanIT technologies and protocols used by other industry participants and

ultimately standards bodies where sought;

Emerging standards that have significant industry traction and are appropriately backed by Living

PlanIT partners;

An ongoing effort with our partners to continually monitor and participate appropriately in the

pragmatic development of relevant standards.

In so doing it is Living PlanIT’s stated intent to provide customers with solutions that will work and interoperate strongly now and in the future and as such protect the value of investments made by customers and partners today; in other words to future-proof UOS implementations

Open Source vs. Open Specification/ Open Protocol

A frequently asked question is whether PlanIT UOS will be open source, the implication being that this would be a good thing from a perspective of future-proofing the application of this technology.

Living PlanIT has no intention to make the UOS open source. Instead, we are adopting a policy of open specification or open protocols, where every interface to the UOS is fully documented and freely licensed to new and existing partners, enabling a vibrant ecosystem to be forged which interoperates seamlessly with the UOS.

To make the UOS open source would mean the following:

All UOS source code would be in the public domain;

Other players would be able to contribute to the code base;

No one entity would be in control of the strategic goals of UOS evolution.

We believe this would manifestly not be in the interests of the community served by the UOS for the following reasons:

Open source has been shown to provide value in some cases for a subset of a technology

marketplace that is commoditized, and providing stability and evolutionary improvement is more

important than innovation (examples include Linux, Apache). There has not been an example to



date of a large scale successful open source project in an area of rapidly developing technology. The

lack of coordination and the absence of focus and investment which a commercial venture can

provide means that this approach will struggle to provide the rate of development needed to make

such a platform a success;

Conversely, in order to justify the investments that it will make in this platform, Living PlanIT needs

to be able to monetize the development of the UOS. This would be very difficult to do in an open

source environment, as we would enable the rapid development of our own competition;

The UOS needs to be highly scalable (both up and down), highly performant, efficient in everything

it does, and uniquely run on a highly distributed private cloud architecture. This requires very

precise and well thought through architecture and design with extremely holistic integration of

different subsystems. This would be almost impossible to achieve in an open source project with

multiple contributors, even if everyone was diligently working towards positive outcomes;

The UOS needs to be particularly secure in order to be successful as the wide scope of information

captured and controls made available makes the platform a target for attack. Opening up the source

code provides ample opportunity for malfeasants to inspect it to look for attack pathways and

removes the potential for undisclosed security traps. This is clearly undesirable;

Since the UOS will collect more data which directly informs or can be used to derive information

about the activity and behavior of residents and visitors, a highly robust identity and privacy

metasystem is essential, and has been designed into the UOS. Making the inner workings of these

mechanisms open source is counter to the design objective, as it would make it far easier for

someone to inappropriately access certain sensitive data;

Open source projects are typically dependent on the efforts of a community for support;

professional support is only available through commercial ventures built on the back of some

version (or distribution) of an open source project (e.g. Linux distributions). Costing studies show

that the lifetime cost of such solutions usually is comparable with the lifetime cost of commercial

software; in other words no cost saving is achieved. Additionally the services and support available

usually fall short of those available from commercial solution providers. Since developers using the

UOS will be looking for high degrees of operational support for an extended lifetime, a well-founded

commercial venture is a better platform on which to build such support;

Building extensive open source solutions on top of proprietary platforms is rarely done, because

this somewhat obviates the rationale for making the solutions open source in the first instance. As

a result, underlying platforms tend to be open source also. This reduces choice for the solution

developer, and may mean building suboptimal solutions compared to existing commercial offerings

particularly in terms of the disadvantages already noted above;

Broad adoption of an open source platform tends to lead to a greater degree of divergence and

sub-variants. And yet for a vibrant ecosystem and maximum choice in interoperable solutions and

components, broad adoption is desirable. Since the interfaces for every instance of the UOS are the

same, equipment integration or applications developed for one project are portable to another,

creating a mass market for our ecosystem. Platform divergence would damage this critical

commercial dynamic;

As demonstrated by the growing number of patent wars between industry players, trolls and other

contributors, it becomes increasingly hard to warranty that in the development of open source



based technologies that at some point intellectual property from 3rd parties has not been

unknowingly or deliberately incorporated into the body of the source;

Where such impingements on 3rd party IP are found, networks or cloud based solutions (as just two

examples) can find themselves under judicial injunction and in default of significant damages for

loss of revenues for the originator of the intellectual property (IP);

Some open source licenses exert strong conditions on the developer of works that include the open

source code, up to and including the need for such derived works also to be open source. This can

cause significant unintended diminution and leakage of IP;

As a result, Living PlanIT develops and delivers all products free of open source code. Furthermore

it warrants to customers and partners that no such code has been incorporated in our platforms

and indemnifies them from all such claims by 3rd parties.

In comparison the benefits of our open specification approach are:

The core of the system is produced by a single commercial entity, leveraging the best available

technologies from the marketplace;

This core can be optimized from concept through to deployment, ensuring required levels of

scalability, performance, and efficiency;

This core can also be secured and designed to ensure that constituent data is appropriately

protected;

The core can be supported through support models synergized with core solution development;

Broad adoption means that more investment can be made in the common core platform to the

benefit of the entire community;

The availability of all interfaces through open specification means that partners have complete

access to the system they require to get the most out of their integration with it and it opens the

door to any partner who wants to build a solution, without having to make any changes to the core

system; which therefore does not have to be rebuilt to accommodate new partners or content;

Interfaces remain stable and functional (best achieved via a commercial organization) maximizing

value to the community;

Open specifications tend to grow vibrant, commercially viable ecosystems of expertise (e.g. OPC,

Wi-Fi, WS-I);

Open specifications reaching critical mass provide the best platform on which to build industry

standards as this accelerates the standard reaching the market in usable form and therefore

adoption.

It should be noted that Living PlanIT may be prepared to put certain items of non-core code into the public domain, or even release as open source under appropriate licenses that do not infringe on customer/ partner IP. This may non-exhaustively include sample code for device integration and applications, and firmware associated with reference hardware designs. The decision to do this would be a strictly commercial one taken by Living PlanIT only.

As adoption of the UOS platform increases and the partner ecosystem expands, Living PlanIT is prepared to consider the following to ensure that the community is optimally protected and supported:

Take open specifications used for UOS interfaces to ISO-affiliated standards bodies to convert a de

facto standard into a de jure on;



Place critical UOS source code into Escrow for the benefit of the partner community in the event

that Living PlanIT, its owners, and/ or successor companies cease to be able to support the UOS.

We believe these measures achieve all that is looked for with an open source solution, without any of the manifold disadvantages.

The roadmap for Living PlanIT making its specifications broadly available as part of the open specification/ open protocol approach is documented in this paper, which will be updated as the platform and the strategy, continues to develop. For the latest information please see our corporate website at www.living-planit.com.

The open interfaces and multiple protocols supported by the UOS provide a wide and efficient set of paths for integrating heterogeneous scenarios with the UOS. These will continue to evolve as standards develop and emerge in order to support the most efficacious and broadly supported interoperability options. If further information is required please refer to the documents referenced herein or alternatively contact Living PlanIT technical support at [email protected].

References

Bettencourt, L.M.A. and Brelsford, C., Industrial ecology: The view from complex systems, Journal of Industrial Ecology 91(2): 195-197. DOI:10.1111/jiec.12243

Chikumbo, O., Goodman, E. and Deb, K., The triple bottomline, many-objective-based decision making for a land use management problem, Journal of Multi-Criteria Decision Analysis, 2014. DOI: 10.1002/mcda.1536.

Chikumbo, O., Lewis, S., Canard, H. and Norris, T., Futuristic smart architecture for a rapid disaster response, In: Disaster Management: Enabling Resilience, Masys, A. (ed), pp 39-64, 2015. DOI 10.1007/978-3-319-08819-8_3.

Resilience Engineering Association. http://www.resilience-engineering- association.org/ , 2014.

Rittel, H. W. J. and Webber, M.M., Dilemmas in a general theory of planning. Policy Sciences 4(2): 155–169, 1973.

United Nations, Department of Economic and Social Affairs, Population Division (2014). World Urbanization Prospects: The 2014 Revision, Highlights (ST/ESA/SER.A/352).

http://www.living-planit.com/



Appendix 1 – Recommended Privacy Policy for PlanIT UOS-based Solutions

Ensure appropriate security of all physical infrastructure by using PlanIT Urban Operating

System™ (PlanIT UOS™ or UOS) ICT infrastructure to protect itself where appropriate including

access control and multi-sensor monitoring of physical infrastructure locations;

Ensure appropriate security of implemented applications through certification;

Minimize personal data stored in solutions wherever possible;

Ensure all personal data stored is clearly identified and marked as such with well-defined

ownership using PlanIT UOS™ data definition tools;

Use a common and coherent identity framework. This can be achieved by using OpenID in

conjunction with PlanIT UOS™ User Profile services;

Use identities for the majority of personal interactions which stop short of first-order identity

credentials (i.e. anonymous, quasi-anonymous and incomplete identities);

Where identity credentials must be stored, partition these so that the minimum is stored in any

one repository and restrict access so that joining up partial identifiers for traceability is made

as difficult as possible;

Where this cannot all be achieved, use a policy-based security framework such as that

implemented in PlanIT UOS™ to ensure privacy protection and regulatory compliance without

explicit configuration being required (explicit configuration does not scale which therefore leads

to error and vulnerability);

Ensure policy is correctly defined, independently audited, fully validated through multiple levels

of intrusion testing, and that access to policy controls is appropriately managed;

Ensure that customers are advised clearly on data that is held about them, the reasons for it

being held, implications if permission to hold data is withheld, policies for management of this

data, and provided with a clear right to opt out of such data being retained;

Optionally/ depending on local regulations – provide mechanisms allowing customers to inspect

data held about them and request its deletion/ anonymization if desired;

Maintain PlanIT UOS™ and all other infrastructure components in up-to-date configurations

taking full advantage of manufacturer’s security updates and recommendations. Test aggregate

security extensively and often.



Appendix 2: UOS Prerequisites for Installers Introduction

There are 5 primary things to take into account ahead of UOS installation:

Overall Hosting Environment

SQL Server Installation Type

Network Access and Domain Name

SSL Certificate

External User ID (OAuth 2/ Open ID Connect ID)

We will describe each of these in turn.

Overall Hosting Environment

PlanIT UOS requires a Windows operating system as well as access to a SQL Server instance (see next section). As the UOS is middleware, a Server operating system is strongly recommended and this should be appropriately configured for an Application Server role.

While UOS can be deployed on Windows clients with additional features such as IIS turned on, these installations are likely to be less reliable and certainly present a larger security risk because of the substantially greater attack surface presented, and while it may be convenient for developers to run such environments, these are not officially supported by Living PlanIT.

UOS can be installed on a physical machine, in a VM, or in a cloud VM. For version 4.1, there is no fundamental difference in how this is achieved. In later releases environment-specific services will be used to provide more optimized support for Microsoft Azure and Amazon Web Services.

Whatever environment is used, UOS Core requires the following configuration to install:

Hardware

X64-based processor

4GB memory minimum

At least one TCP/IP network connection

500MB minimum disk space over operating system / prerequisite install

Data storage to suit data feed, depth, and retention requirements

Software

Microsoft Windows Server 2008 R2 or later (Application Server role)

Microsoft SQL Server 2012 or later Express or higher

(SQL Server 2008 R2 can be used if necessary but this precludes use of the Excel interface)

.NET Framework 4 Full client

Developer Client Standalone installation may be on Windows 7 or later, with development client of choice eg. Visual Studio.



For RTC driver/ control application development Mathworks MATLAB/Simulink Embedded Coder/ MATLAB Coder/ Simulink Coder/ Stateflow at version R2009a – R2011b are required.

Our recommended minimum environment is as follows:

Hardware

Minimum 2-core processor

16GB memory

500GB system disk

500GB data disk (can be combined)

Software

Microsoft Windows Server

Microsoft SQL Server 2012 / 2016 Standard

PlanIT UOS RTC hosting and installation details will be provided on request to those embedding the

product.

SQL Server Installation Type

The UOS uses Microsoft SQL Server as its persistence engine. An abstraction layer allows use of other RDBMS but at the time of writing only SQL Server is supported. Please consider before installation what type of SQL environment you require. There are three principal options:

standalone SQL Express installation (one RDBMS per UOS node)

standalone SQL installation (one RDBMS per UOS node)

farm SQL installation (RDBMS shared by multiple UOS nodes)

Please note that from the installer perspective, the latter two options are indistinguishable. The farm solution can yield some performance advantages in a multinode environment but it does require more expansive network access.

The UOS installer can provide an integrated instance of SQL Express (option 1 above), which is a free license, but is only capable of storing up to 10GB of data. If you require a larger database - and most scenarios will - please install an instance of full SQL Server (standard is normally sufficient) and be ready to provide connection parameters when requested by the UOS installation routine (options 2 and 3 above).

Network Access and Domain-based Machine Names

As a middleware server product, the UOS needs to be installed on an IP network. It is beyond the scope of this guide to provide extensive recommendations for how this is set up, but please bear in mind that the security of any system is derived in no small part from its infrastructure, and the network is a substantial part of this infrastructure.

For an intranet system that does not require connection to the internet, this is probably a relatively straightforward set of choices. You will be running your own DNS or other addressing schema, and machine/ domain names should be chosen to suit, or alternatively IP addresses may be used. It is normal still to separate medium and large internal networks into subnets, potentially with finer grained topology than buildings and campuses, and access between subnets needs to be borne in mind when planning a UOS installation, particularly if multinode architecture is to be used. Please see system documentation for more details.



For a system which operates via or with the internet, more advanced considerations need to be borne in mind. This is likely to be deployed and run in conjunction with other internet connected services, and where UOS is available to the internet, configurations such as DMZs or reverse-proxy firewalls are likely to be found. A public IP address will need to be allocated to each reachable node deployed in your UOS cluster, and these machines will need to be configured with appropriate machine identifiers which match your domain name structure and your DNS records. Please note that where a SQL Farm topology is used or where certain UOS nodes in a multinode cluster are not needed to be Internet-accessible, these nodes can be set up without public IP and using internal addressing schemas.

Cloud environments are usually more straightforward because internet accessibility is designed to be easily achievable and more the norm. Please be aware however of considerations such as limits on the number of externally accessible IP addresses which can be allocated to VMs and there is still a need to allocate appropriate machine names based on domain structures.

Please note that definition of naming structures ahead of obtaining appropriate certificates (see next section) is required unless root certificates are being used.

SSL Certificate

UOS is addressed via RESTian web services, which are hosted in Microsoft IIS. In order to secure these interfaces, SSL is mandatory throughout and is also used for the Admin UI. As a result, an SSL certificate is required for each UOS Supervisory node. For a production system, this should be a public SSL certificate obtained from a trusted Certificate Authority. For local testing purposes it is possible to run UOS with a Self-Signed Certificate can be used. In this case to establish trust, application servers and clients accessing UOS APIs need to add the UOS hostname to their Trusted Hosts list. If this is not done, UOS API calls will fail, and attempts to access the Admin UI will result in web browser warnings about the insecure certificate.

Certificates should be imported into IIS ahead of installing UOS where feasible. Details on Certificate Management can be found in the UOS system documentation installation guide.

External User ID (OAuth 2/ Open ID Connect ID)

The UOS uses Open ID Connect, an extension to OAuth 2.0 as its user identity system. This allows UOS IDs to be federated with public authentication providers - in release 4.1, Facebook and Google IDs are supported. Microsoft IDs will be added in a later release.

UOS has its own Open ID provider which supports local IDs particularly for intranet systems with no internet connectivity. An initial local administrator ID is created as part of the installation process in order to guarantee that one local admin ID is always available in case of critical scenarios such as DDOS attacks. However it is recommended that a secondary external Administrator ID is created and this can be performed during the install process. If this is desired, please ensure an appropriate ID has been created on the desired site and is available at install time. Please see system documentation for more details.

To obtain your Google Account URL:

Go to https://plus.google.com/ and log in

From the Home button select the Profile option, your Google ID will be shown in the browser URL

bar, make a note of the URL (ignore the text at the end). Example OpenID URL:

https://plus.google.com/123456789012345678901

https://plus.google.com/



IMPROVING QUALITY OF L IFE THROUGH TECHNOLOGY

WWW.LIV ING -PLANIT.COM

Introduction to UOS Architecture White Paper

Documents

Transcript of Introduction to UOS Architecture White Paper