This document discusses concepts related to smart cities and their information modeling. It begins by defining a smart city and outlining some of its key components. It then provides examples of concepts that could be included in an information model for city systems, such as organizations, alerts, incidents, assets, and locations. It also discusses existing standards that could be leveraged for modeling these concepts and provides examples of their current use. Finally, it presents an approach for developing a semantic model called SCRIBE that is aligned with standards, customizable for different city needs, and extensible.
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
http://theurbantechnologist.com/2012/09/26/the-new-architecture-of-smart-cities/
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”: http://theurbantechnologist.com/2012/09/26/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.