Smart Cities that don't go "bump" in the night: delivering interoperable smart city systems using Open Standards

Uploaded on

I gave this presentation at the launch of the British Standards Institute's development of standards for interoperability between Smart Cities systems. It draws on my experience delivering …

I gave this presentation at the launch of the British Standards Institute's development of standards for interoperability between Smart Cities systems. It draws on my experience delivering large-scale, standards-based technology architectures. Whilst Open Standards will be absolutely crucial to the delivery and operation of interoperable, open Smart Cities systems, they are not a panacea, and it's vital that we're aware of their limitations as well as their value.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Barack Obama used his twitter account to great effect in winning his first Presidential Election. However at one point during the campaign, a Twitter administrator’s account with a weak password was hacked using a dictionary attack. Barack Obama’s account was one of those that the hacker gained access to, resulting in a series of inappropriate tweets reaching his 155,000 followers.

    When technology is used to influence or control real-world systems, technology failures can have significant real-world impacts.
  • There are thousands of examples of IT projects that run into difficulty, or that deliver unsatisfactory systems, because of failures of communication between the very many stakeholders involved; from misinterpretations of business requirements to mis-communication between project teams. Any experienced IT deliver person will recognise all of the problems illustrated by this cartoon.
  • First, we need to agree what a Smart City is. This is the most succinct and open definition I use.
  • Secondly, we’ll need common understanding across all of the very many areas of concern involved in Smart Cities, from environment to technology infrastructures to systems such as healthcare and water supply, through communities and cultural ecosystems to governance and politics.

    This diagram is taken from my article, “The New Architecture of Smart Cities”:
  • The objective of Smart Cities isn’t to create a financial profit – though they must demonstrate some form of financial value in order to attract investment. The real objectives are usually social, environmental and economic. There are strong resonances with the concept of the “triple bottom line” and social capital. But brand value is also important, as cities seek to attract residents and businesses in a globally competitive market.
  • When IT projects fail, they usually fail at the interfaces between systems. As technology becomes embedded in more and more physical and social systems, we are creating new interfaces that we have never built before. The risk of failure is therefore high, and we need to design those interfaces carefully to avoid failure as far as possible; and to mitigate its effects. One way to do that is to create new standards that professionals in technology, construction, social care and politics can all use, along with citizens, communities and businesses, to at least build a common understanding of how those interfaces should behave.
  • This spreadsheet illustrates the difference in culture between the IT industry and the engineering and construction industries. In IT, the prevailing culture is to assume that a project is proceeding successfully unless it can be demonstrated to be failing, or to be exposed to unacceptable risk. In the engineering and construction industries, projects are not assumed to be successful until it is proved they are deliverable on time.

    I once saved a deeply troubled, multi-£100m IT programme by adopting construction culture, not IT culture. This spreadsheet was colour-coded red for every element of every project that could not prove it had committed resources to address every issue in it’s project plan. “Rick and Dave’s big red spreadsheet” – printed out on A2 paper and walked around the office of the company running the project – drew attention to the number and severity of issues affecting the programme, resulting in a restructuring that enabled it to be successful.

    It’s already hard enough to deliver projects successfully in the IT, construction and engineering industries. When we bring them together; and attempt to address issues in the complex, emergent, human context of cities, we’ll multiply the challenges. Standard approaches to expressing targets, measuring progress towards them, and characterising and quantifying risk will be needed if we are to succeed.
  • This diagram describes part of the project methodology by which IBM governs the delivery of complex IT projects. Most successful organisations have similar formal methods (“agile” methods are structured very differently to traditional methods; but they are still methods). The most experienced project delivery expert that I know once told me “if you see no method applied to project governance, be worried. If you see two or more methods, be terrified”.

    Smart cities projects will involved teams and companies drawn from a wide variety of disciplines and sectors. They will all have very different methods of delivering projects successfully. Unless we can at least align those Methods to each other, it will be very difficult and risky to deliver Smart Cities projects successfully.
  • Smart Cities solutions involved systems in many different domains – utilities, social care, education, culture – integrating successfully together.

    But integration, especially of such complex systems, is not easy.
  • These are just a small number of the “entities” that my colleagues realised needed to be used in common descriptions of maintenance work carried out on roads and utility systems in cities – a tiny subset of the overall number of systems.

    It’s actually very laborious to define any of these entities in a way that is sufficiently detailed to be useful; and in a way that organisations and individuals as different as city councils, gas companies, homeowners and traffic officers will agree to.
  • And there are already a plethora of different standards describing these entities from different perspectives. This is just a sample of the existing samples my colleagues found.
  • As a result, one of the pieces of research work IBM is undertaking – in partnership with Universities around the world – is to attempt to build a common “meta-model” of information and entitites relating to city systems, so that we can start to understand the scope and complexity of the work that will be involved in integrating them together.

    Of course, you don’t need this level of analysis if you simply need to integrate a works management system for pavements with a works management system for gas pipes – that individual piece of work is much simpler.

    But if we aspire eventually to achieve the widespread integration of information from city systems – either in order to operate them more consistently and effectively; or to release that information to citizens, businesses and communities as open data in a form that is useful to them – then we need to recognise and tackle this important and complex problem.
  • The good news is that there are plenty of efforts underway to do this. One example is the EU-funded “European Platform for Intelligent Cities”, in which IBM is one of many participants.
  • Open standards for Smart Cities will be an incredibly important tool for addressing the issues that I’ve described; but it is not a panacea.

    In the early days of internet computing, the development of the J2EE Open Standard played a tremendously important role in reassuring customers that the products of companies such as IBM and WebLogic (now owned by Oracle) could allow them to adopt internet computing without becoming “locked in” to a single vendor’s platform – a concern now shared by all of the cities that I speak to about Smarter Cities.

    In theory, the fact that both IBM and WebLogic’s products complied to the J2EE standards meant that customers could build applications that could be moved from one to the other – or to Open Source offerings such as JBoss – with minimal effort.

    But reality is always more complicated. Writing and agreeing an Open Standard that completely describes the behaviour of something as complex as a Web application server is a very complex task. In 2002, the EJB 1.1 specification, part of the J2EE specifications, was supported by both IBM and WebLogic. However, the specification omitted to describe a crucial aspect of how Web applications servers should interact with databases. Vendors such as IBM, JBoss, WebLogic and others had to chose a way to address the issue, and all chose different approaches, with the result that applications were not in fact portable between platforms. This issue was addressed several months later in the EJB 1.2 specification, but in the meantime customers faced the hard choice of developing applications that could only be moved between platforms with effort; or delaying the business applications that they needed.

    Similar issues are absolutely guaranteed to occur through the development of Smart Cities standards by the BSI , City Protocol Society , OASIS, ISO and all of the other relevant standards bodies – the systems involved are just so rich and complicated that there’s simply no way to get the standards right and complete first time.

    Technology providers, the Open Source community, standards bodies and cities should all be very open about these issues – they should not be hidden deep in technical documentation. Smart Cities systems will affect real lives, and be involved in life and death situations. Edward Tufte’s analysis of the Challenger Space Shuttle disaster showed that the crucial information that predicted the disaster would happen was presented by engineers to NASA’s managers long before the disaster. But is was buried as a small detail in complex technical presentations. We must not make that mistake with Smart Cities standards as we develop them.


  • 1. Copyright © 2012 BSI. All rights reserved. Cities that don’t go bump in the night Rick Robinson, Executive Architect, Smarter Cities, IBM 02/07/2014
  • 2. Copyright © 2012 BSI. All rights reserved. 2
  • 3. Copyright © 2012 BSI. All rights reserved. 3 What do we want? 02/07/2014
  • 4. Copyright © 2012 BSI. All rights reserved. 4 What is a Smart City? • A Smart City is one that is fully exploiting developments in science and technology to enable a successful future of equitably distributed, sustainable growth.
  • 5. Hard Infrastructures Spaces and buildings Transport and Utilities network Information and Communication Technology Soft Infrastructures Networks and Community organisations Innovation forums Leadership and governance City Systems Transport Services Health Culture Economy City Admin Utilities Social Care Public Safety Education Others... ? Public Sector Community Private Sector Others ... ? Schools Emergency Services Council 3rd Sector Others ... ? Social Enterprises Not-for-profits Charities Others ... ? SMEs Retailers Employers Others ... ? Neighbourhoods Cultural & Religious Independence Choice Sustainability Others ... ? Wealth Opportunity SafetyHealthGoals Citizens, Employees, Innovators, Visitors ...People Ecosystem Family & Social
  • 6. Copyright © 2012 BSI. All rights reserved. 6 Smarter Return on Investment 02/07/2014 Positioning the organization for future success and competitive advantage. Strategic value Brand value Operation value Societal value Strengthening perception, reputation and influence. Improving existing operations and creating new capabilities. Creating social, cultural and environmental benefits.
  • 7. Copyright © 2012 BSI. All rights reserved. 7 Will it work? 02/07/2014
  • 8. Copyright © 2012 BSI. All rights reserved. 8 Delivery cultures 02/07/2014
  • 9. Copyright © 2012 BSI. All rights reserved. 9 Delivery methods 02/07/2014
  • 10. Copyright © 2012 BSI. All rights reserved. 10 Will things work together? 02/07/2014
  • 11. Copyright © 2012 BSI. All rights reserved. 1102/07/2014 • Organization • Definition: A group of persons organized for a particular purpose • Examples: Police department, public housing department, bus department, transportation agency, water agency, electric utility • Key attributes: Name, type of organization, description, identification, website • Key relationships: Organizations (parent-child), assets, location • Standards assessment: National Information Exchange Model (NIEM): NIEM-Core (nc:)OrganizationType, UCore (Universal Core) organization • Alert • Definition: A warning or alarm for an imminent event • Examples: Road repair advisory • Key attributes: Sender, description, urgency, severity, certainty, onset time, location, supporting resources • Key relationships: Sender (organization or person), location, incident, work orders • Standards assessment: The Common Alerting Protocol (CAP) has extensive support for the alert concept. The UCore Event concepts are also applicable. • Incident • Definition: An occurrence or an event that may require a response • Examples: Road repair, automobile accident, water main bursting, criminal activity • Key attributes: Date and time of the incident, description, ID • Key relationships: Location, alerts, work orders, owner (organization or person) • Standards assessment: NIEM:nc:IncidentType, CAP:alert:incidents, UCore Event, Service-Oriented Architecture (SOA) Ontology Event • Person • Definition: A human being, an individual • Examples: James, Bob, Sally • Key attributes: Full name, given name, family name, gender, date of birth, place of birth, citizenship, country of birth • Key relationships: Employer, location, address, organization, role (such as operator, supervisor, responder, analyst, asset manager) • Standards assessment: NIEM:nc:PersonType, UCore Person, SOA Ontology Human Actor • Asset • Definition: A tangible object that can be tracked over time • Examples: Road, water pipe, electric capacitor, bus, building • Key attributes: Description, ID • Key relationships: Organization, person, manufacturer, location, work order, incident • Standards assessment: NIEM:ip: AssetType, UCore Entity • Work order • Definition: An order to do some work; to fix, repair or replace • Examples: Road repair, utility maintenance on a main valve, re-routing of buses • Key attributes: Description, ID, comment, priority, status, location, start date/time, stop date/time • Key relationships: Work steps, work orders (parent-child), incident, alert, organization, maintenance history, specification, person, assets • Standards assessment: No relevant standards identified at this time. • Process and procedure • Definition: A series of actions to accomplish a goal • Examples: Road repair notification and coordination • Key attributes: Process document • Key relationships: Process steps, work orders, incident, alert, organization, person, assets • Standards assessment: SOA Ontology Process • Key Performance Indicator • Definition: A measurement or criteria to assay the condition or performance of a person, process, or thing • Examples: Response time, time to closure, cost to city, savings to city, impact to city services • Key attributes: Description, metrics, thresholds • Key relationships: KPI (parent-child), organization, incident, alert, process and procedure, asset • Standards assessment: No relevant standards identified at this time. • Location • Definition: A geographic place, point, position, or area identified by its coordinates in an earth based coordinate system, name, or address • Examples: Road repair location: city intersection, water pipe location • Key attributes: Geographic coordinates, postal address, TimeStamp • Key relationships: Person, organization, asset, incident, alert • Standards assessment: NIEM:nc:LocationType, UCore Location, Geography Markup Language (GML) Point, OpenGIS® Open Location Service (OpenLS) Location • Time • Definition: Measuring system used to sequence events, to compare the durations of events and the intervals between them, and to quantify rates of change such as the motions of objects • Examples: Start time, end time • Key attributes: Years, months, weeks, days, hours, minutes, seconds, milliseconds • Key relationships: Duration • Standards assessment: NIEM:nc:DateTime, W3C DateTimeDescription
  • 12. Copyright © 2012 BSI. All rights reserved. 12 Information models for city systems 02/07/2014 Standard Examples of supported concepts Current deployments Common Alerting Protocol (CAP) Category, status, scope, certainty, severity, urgency, onset time, expiration time, response type, instructions International standard (OASIS plus ITU-T Recommendation X.1303) with deployments primarily in the U.S., which include: Department of Homeland Security, National Weather Service, United States Geological Survey, California Office of Emergency Services, Virginia Department of Transportation, and Oregon RAINS. National Information Exchange Model (NIEM) Activity, address, case, date and time, document, item, incident, location, organization, person U.S. specific, with deployments that include: U.S. Department of Homeland Security, U.S. Department of Justice, U.S. Citizenship and Immigration Services, Federal Emergency Management Agency (FEMA), Law Enforcement Information Sharing Program, Logical Entity eXchange Specifications, OneDOJ, and the Department of Health and Human Services. OpenGIS Geography Markup Language (GML) Point International standard (OGC) that is widely used in the industry, and considered the reference in its space. OpenGIS Location Services (OpenLS) Location International standard (OGC)that is used for location based applications such as cell phone apps. SOA Ontology Service, process, task, event, human actor, effect, system, policy, service contract, service interface, element International standard (TOG) that encapsulates SOA vocabulary and relationships and is used to describe and model SOA solutions. Universal Core Entities and assets, events and alerts, people, organizations, locations, collections U.S. specific standard that is jointly managed by Department of Defense, Justice, and Homeland Security, and the Office of the Director of National Intelligence. Within the DoD, the Marine Corps, Navy, and Air Force appear to be committed to supporting UC. W3C Time Ontology in OWL Interval, DurationDescription, DateTimeDescription, DayOfWeek International standard (W3C) with and uncertain adoption. Our web search revealed no concrete deployments.
  • 13. Copyright © 2012 BSI. All rights reserved. 13 Authoritative •Aligned with standards (CAP, NIEM, MISA/MRM, UCore) •Validate with customer scenarios •Validated with open city data Simple language •Classes + Inheritance + Relations + Inferencing •Based on standards (OWL-QL, SPARQL) •Mappable to UML •Metadata annotations and Tagging SCRIBE Core Model City Customization Common building blocks Extension Weather Water Transportation BuildingAndParcel AssetManagement Simple language •Classes + Inheritance + Relations + Inferencing •Based on standards (OWL-QL, SPARQL) •Mappable to UML •Metadata annotations and Tagging Organization/Operation profile Features Authoritative •Aligned with standards (CAP, NIEM, MISA/MRM, UCore) •Validate with customer scenarios •Validated with open city data Simple language •Classes + Inheritance + Relations + Inferencing •Based on standards (OWL-QL, SPARQL) •Mappable to UML •Metadata annotations and Tagging Authoritative •Aligned with standards (CAP, NIEM, MISA/MRM, UCore) •Validate with customer scenarios •Validated with open city data SCRIBE: a non-normative, authoritative, modular, extensible semantic model for Smarter Cities.
  • 14. Copyright © 2012 BSI. All rights reserved. 14 Smarter City platform architectures: EPIC (BCU / IBM / Deloitte), DCE (Imperial), IOC (IBM), UoS (Living PlanIT) ... 02/07/2014 From the European Platform for Intelligent Cities project
  • 15. Copyright © 2012 BSI. All rights reserved. 15 Cautionary tales • The EJB specification does not provide a standard mechanism to let the container check if the bean's state has changed within a unit of work. • The specification assumes that all beans accessed during a transaction are "dirty," and must have their state written back to the persistent store at the end of a transaction. • WebSphere provides an extension to the EJB specification with the const method flag in the deployment descriptor of entity beans. It lets the developer tell the container which methods are const or read-only--in other words, it doesn't change the state of the bean. For these methods EJB container does not call ejbLoad at the end of the method call. J2EE vendor documentation, approx. 2002 02/07/2014