Framework for SMART City Deployment V1.0

Framework for
SMART City
Deployment
TechniCity Project Report V1.0
Paul Goff
5/25/2013

An exploration of a conceptual framework that might be adopted by any
municipality or community and enables that organisation to deploy the physical
and logical infrastructure required to support all SMART functional technology
going forward.


Framework for SMART City Deployment

Terms of Reference

Introduction

The brief for this informal report is to explore a conceptual framework that
might be adopted by any municipality or community and enables that
organisation to deploy the physical and logical infrastructure required to
support all SMART functional technology going forward.
Objective

In my role as head of ICT within Buro Happolds Urban Intelligence Group (UIG)
http://www.burohappold.com/thelivingcity/urban-technology/ I have
contributed to several technology and SMART city masterplans for existing and
proposed developments around the world. There are consistently several
common issues that crop up during strategy development and typically leave
project teams, municipalities and city authorities scrambling for a way forward.

The objective of this report is to support the practical deployment of technology
and infrastructure within the public realm and focus efforts within the city at a
macro rather than micro level by summarising the potential issues to be
considered during the SMART planning process.

One major factor is approaching strategy development with a ‘top down’
perspective focusing resources on pursuing specific applications and functional
technology, typically because it makes for an easy sell when seeking senior
backing or financial support.

By documenting these issues (even if only at a high level) it is hoped this report
may assist those tasked with initiating projects in the SMART city arena.

2

Inevitably this approach opens the door for systems and equipment
manufacturers to promote the deployment of proprietary, closed protocol,
solutions.

Issues
I had hoped to focus the emphasis of the report on the efforts of one or two
London based City councils in order to use their experience as a baseline for the
proposed framework.

SMART city implementation should, in the first instance, focus on objective
setting whilst planning a physical and logical infrastructure that's capable of
providing a platform for systems integration in support of those objectives for
a period of between 15-30 years.

Unfortunately this hasn’t been feasible due to issues engaging with the
appropriate departments and individuals within the timescale stipulated.

In other words a bottom up approach focussing on:

Assumptions
Those seeking to utilise the framework recognise the legacy approach to the
deployment of technology and information systems within the confines of the
city as a constraint e.g. without an appropriate strategy in place numerous,
disparate, proprietary systems and infrastructures will be implemented.

•
•
•
•

Spatial planning for physical infrastructure - civil engineering;
Network design – data communications engineering;
Implementation of open protocols for control and supervisory platforms software engineering;
Development of suitable middleware and data bases to hold the whole thing
together - computer science;



Information Technology Requirements
The criticality of a bottom up approach can be best appreciated by considering
industry best practice for the lifecycle of technology deployed in the public
realm and encompassed in the following figure:

Layer 4 User Requirements Layer
•Lifecycle 3-5 Years

Layer 3 Network Layer
•Lifecycle 5-10 Years

Layer 2 Transmission Media Layer
•Lifecycle 10 -15 years

3

Transmission Media Layer
The physical or wireless medium utilised by the technology in question e.g.
copper, optical fibre or radio waves. This layer will be expected to provide 10 15 years’ service, particularly cabled infrastructure which should support several
generations of application and transmission equipment.
The Infrastructure Layer
Encompassing above and below ground space and the infrastructure required to
support the media layer. For example underground ducts and interconnecting
chambers, building entry points, equipment space etc. This element of the
overall solution should be designed to provide the city with at least 30 years’
service with minimal requirement for maintenance or further invasive civil
engineering works.

Layer 1 Infrastructure Requirements Layer
•Lifecycle 30 Years +

ICT Requirements Model

User Requirements Layer
Typically consists of software, user interfaces and functional technology,
applications will have short lifecycles typically in the region of 3-5 years and will
be highly dependent upon the specific requirements of the city.
Network Layer
Refers to the data communication technologies required to deliver the city’s
user applications. This layer may represent Gigabit and 10 Gigabit Ethernet
transmissions, leased ‘point to point’ services and fibre to the premise (FTTP).
Services at this layer tend to have lifecycles in the region of 5 – 10 years.

SMART City Infrastructure
Clearly defined objectives for a city are likely to incorporate at least some key
performance indicators (KPI’s) associated with the management of resources,
facilities and operations.
Seeking improvement in one or all three of these KPI’s inevitably leads planners
to consider integrating new and existing systems and processes typically
enabled via two key technical areas, namely:
•

Convergence and the ability for numerous systems to communicate across a
single physical and logical medium regardless of signal type or transmission
protocol. Converging systems will increase the functionality provided by
existing platforms whilst simultaneously providing opportunities for
reduction in capital and operating expenditure.


•


The ubiquitous deployment of wired and wireless intelligent devices, SMART
sensors and actuators interconnected via an appropriately planned ICT
infrastructure. These intelligent devices will be used to automate day to day
management of the city and its resources including utility infrastructures,
municipal building management systems, transport systems and the
operation of the public realm.

SMART City Framework

framework or methodology that will treat the city and its commercial partners
as an enterprise.
Numerous systems exist for modelling an enterprise and its systems but in the
spirit of an open approach the following figure utilises elements of the TOGAF
(http://www.opengroup.org/togaf/) ADM architectures that could be used to
develop the basis of a strategy.

In the authors opinion the business case for a SMART city project initiation
should encompass the following five conceptual work streams.
ENTERPRISE ARCHITECTURE
DATA COMMUNICATIONS & INFRASTRUCTURE
CONTROLS & CITY OPERATING PLATFORM INTEGRATION
ANALYTICS
APPLICATIONS
SMART City Framework

I have tested these opinions amongst colleagues and industry peers utilising
numerous forums including social media – see the appendix for a summary of
responses to the framework concept collated via ‘LinkedIn’ group discussions.
Enterprise Architecture
A legacy approach to the deployment of information technology systems within
the city will be a constraint e.g. disparate proprietary systems and
infrastructures owned and operated by multiple factions, agencies etc.
Integration and convergence of physical and logical systems is the key to a
successful SMART deployment.
In order to navigate the commercial relationships and governance issues
associated with this level of integration it is important to utilise a recognised

SMART City Enterprise model

The engineering challenges encountered when developing and implementing
city systems are numerous but as a relatively new concept the commercial
issues which need to be resolved to enable the technical challenge to begin can
prove to be overwhelming to a project team without the assistance of an
appropriately qualified enterprise architect.

4



The following figure highlights some of the SMART city ‘enablers’ that need to
be navigated and managed (typically across multiple organisations) when
mapping city enterprise architecture in order to begin to implement SMART
functionality.

5

The importance of aligning technology infrastructure and topology with energy
technology,
policy for the city cannot be overstated for example an incorrectly specified
overstated,
meter strategy could constrain all future energy proposals for the city including
demand response and load shedding.

SMART City Enablers Vs SMART City Functionality

For example community leaders may aspire to influence or improve the
utilisation and management of energy within the confines of a ci through the
city
introduction of a municipal energy bureau and a SMART energy grid.
This is the goal of many cities around the world (particularly newly proposed
schemes in the developing world) however this aspiration typically entails
navigating numerous complex issues of governance and tenure, not least
ownership of the city’s electrical distribution infrastructure.
Energy bureaus and /or SMART grids require the deployment of i
information
technology systems to integrate numerous processes including meteri and
metering
billing along with consumer databases. Physical implications for communications
infrastructure include resolution of a suitable metering strategy and connectivity
of said meters to site wide ICT networks.

Conceptual Components of a SMART Grid

Data Communications & Infrastructure
Development of this work stream will encompass deployment of resilient city
wide fixed and wireless physical telecommunication infrastructure and outside
plant.
Typically these elements of a SMART city i
infrastructure are encompassed within
the physical (layer 1) and data link (layer 2) layers of th OSI model as developed
ayer
the
by the ISO (http://www.iso.org/iso/home.html
http://www.iso.org/iso/home.html).



Typically layer 1 will dictate the physical space allocated to cable routes, civil
infrastructure, central plant, street furniture, wireless and cellular infrastructure
and equipment rooms.

6

halls, fire stations etc. with optical fibre and the appropriate light wave
equipment.

Layer 2 will fix on network technology and the associated implications of that
technology on the proposed topology of infrastructure for example Fibre to the
premise (FTTP), metropolitan area networks (MAN) etc.

By deploying an appropriately specified MAN the city relinquishes any obligation
(and cost) to incumbent telecom operators for interconnecting city owned
buildings. The MAN can also be used to support telemetry from city wide
services such as transport and security and forms the basis for the backhaul of
data traffic generated via municipal WiFi in the public realm.

In the first instance strategy developed under both layers should be standards
based in order to avoid deploying proprietary systems. Inevitably the
deployment of fixed infrastructure and technology assets will be linked to
discussion around capital investment, operational expenditure, tenure and
possible revenue generation.

Finally the implementation of a MAN can provide the city with a backbone that
will enable the deployment of true SMART city functionality through the
introduction of city wide control rooms and city operating platforms.
The following figure presents a hypothetical topology utilised to deliver SMART
city functionality to residential and commercial property via a fibre optic
infrastructure and a distributed city operating system (COS) with nodes co-

For example a city may aspire to deploy an ‘open’ access telecom infrastructure
with cabled and civil networks remaining the property of the community they
serve. In this scenario revenue will be generated through
charges raised against telecom operators utilising the
Hypothetical Distribution of SMART City Services via Municipal Telecom Infrastructure
infrastructure to deliver voice, data and video services to
the occupants of the city.
In variably the cost of constructing and maintaining such
an infrastructure proves too prohibitive for many cities
and municipalities. However its important city leaders
consider all elements of network ownership maybe
opting to retain civil infrastructure whilst leasing cable
placement within duct space to operators.
Alternatively many city’s opt to deploy higher level
infrastructure such as metropolitan area networks which
can be developed on a more gradual basis by
interconnecting major municipal hubs such as town



7

located in telecom points of presence (PoP) buildings and interconnected via a
MAN.

the developments facility management team in association with the City’s street
works team.

The author has direct experience of the complexity of trying to plan and
implement solutions for both layers 1 and 2 within the cityscape and the
following example emphases the difficulty faced when deploying even the
simplest technology infrastructure in the public realm.

Reaching this solution entailed multiple rounds of negotiation with all factions,
developing a design for physical infrastructure that aligned with the technical
and security requirements of all concerned. Proposing a financial model that
enabled the developer to recoup the cost of the engineering works from the
telecom operators who have to pay each time they access the infrastructure and
then locating the access point and 2 x chambers equidistant to all of the
operators existing underground infrastructure.

In summary a major developer was seeking the provision of additional building
entry points, situated within the public realm, for a high profile retail and office
complex that had only recently been completed in the City of London (the
financial district within Greater London).
The developer had a potential tenant who required resilient, high bandwidth,
fibre optic telecommunication connectivity to be provided to this office space by
multiple operators in order to sign up to a long term lease.

The preceding narrative and following figures and photographs (source: Buro
Happold) provide some idea of the complexity involved in retro fitting a
relatively simple infrastructure solution in a busy public realm.

Historically in the UK, telecom operators will not share above or below ground
infrastructure. The potential tenant required high bandwidth data connectivity
to be available from a minimum of 5 service providers, the City Of London
authority did not want to see large scale, invasive engineering works in the
footway adjacent to such a high profile development and the developer wanted
to retain some element of control over his multi tenanted building rather than
allow 5 telecom organisations free reign as to the location of their building entry
points.
This issue is typical of the conundrum faced by developers and municipalities
around the world e.g. the importance of tenure, governance and physical
infrastructure to the deployment of technology within new and existing cities.
Street Scene Prior to Works Commencing

The solution in this instance was to develop a proposal for one new building
entry point, to be located in the public realm and controlled and managed by



Street Scene Post Works Commencing

Multiple Operators Cabled Infrastructure Utilising a Shared Duct Infrastructure

Single Multi Operator Building Entry Point

8



Controls and City Operating Platform Integration
The integration of city wide information technology systems refers to the
process of linking together different computing platforms, applications and
infrastructure physically or functionally to act as a coordinated whole.
Applied holistically across the city by enforcing open interfaces between various
systems, sensor streams and supervisory platforms this integration becomes a
powerful tool e.g. the basis of a city operating system.
The term city operating system has become common place often associated
with control, sensing and supervisory capabilities within the confines of the city.
The architecture of a city operating system must be based on a model with the
potential for evolution and innovation making production of new system
components attractive to third parties and a range of alternative organisations.
The following figures encompass key components of a city operating system:

As previously discussed the integration of city wide information technology
systems refers to the process of linking together different computing platforms,
applications and infrastructure under a SMART urban architecture.
This SMART urban architecture will encompass an operating platform and
physical network topology that maybe be owned by the city and deployed
within dedicated civil infrastructure.
At the edges of this infrastructure e.g. dwellings, commercial property, smart
networks deployed in the public realm etc. there will be a mix of interfaces –
fixed & wireless supporting a range of intelligent devices including sensors and
actuators.
The core infrastructure supporting backhaul transmission of data and telemetry
on this network will be an optical fibre infrastructure owned and deployed by
the city.

Real time
control
capability at a
micro and
macro level;

A platform
designed to
provide data and
control capability
to applications
developed by third
parties;

9

An integrated
platform for
multiple types
of control and
sensor;

Supervisory and
analytical
capabilities for
large quantities
of historical
data;

Key Components of a City Operating System



It’s reasonably safe to assume the city’s data sources, facilities and proposed
services will be managed by a combination of a city operating platform such as
Living PlanIT’s Urban Operating System (UOS) http://www.living-planit.com/
and this dedicated optical fibre network.

The following tables highlight typical bandwidth implications that maybe
encountered during the detailed design of SMART urban architecture for a city.
IP CCTV Network Bandwidth Estimates

For example sensors deployed within the various building envelopes, the public
realm or alongside utility infrastructure will be co-located with actuators.
Wireless Access Points Network Bandwidth Estimates

When a light sensor in an apartment is activated an actuator will switch on a
light. Within an individual apartment during a typical day this type of real time
control (RTC) occurs on numerous occasions for lights, AC, operation of white
goods etc.
As an individual local issue this RTC is of low priority to the operation of the city,
however an aggregated log of these actions and the RTC instances from
surrounding apartments within the same block will be of interest and will be
transmitted to a UOS node on a 15 minute, 60 minute or daily basis.
These transmissions will be prioritised via the UOS in order to take advantage of
quieter periods of network traffic e.g. information pertaining to the operation of
site wide transport information will be a far higher priority than energy
utilisation in an individual apartment.
The sensor networks deployed within each dwelling, commercial property or
streetscape will be interconnected to the UOS via dedicated control panels
utilising a combination of fixed and wireless interfaces.
The UOS sees these control panels as another sensor in the deployed network
and each individual control panel will be physically connected to a UOS instance
via dedicated fibre optic cabling.

10

Sensor Network Bandwidth Estimates

SMART City Network Bandwidth Aggregation Issues

UOS nodes will be distributed across the city and network design should focus
on placing them in densely populated areas in order to reduce physical
infrastructure requirements in a similar fashion to planning fixed
telecommunications infrastructure.
The minimum number of UOS instances or nodes to be deployed as part of a
metropolitan project will be 2 in order to provide a resilient platform for the
city.
UOS nodes can be physically located in the building distributors and computer
rooms of MDU’s & MTU’s, in telecom PoP’s, in commercial data centres or in
street side enclosures and cabinets.



11

Distribution of UOS Nodes within the SMART City

Analytics
This work stream entails the development of a computing platform capable of
collating city wide data at an industrial scale e.g. thousands of data streams
operating at a macro and micro level, in other words ‘big data’.
With the appropriate systems in place the ability to store manage and
manipulate data under this work stream will create massive opportunities for
the city as well presenting ethical issues such as who owns this data and how
can it best benefit the city and its population.

Applications & Analytics are Components within a City Operating Model

Applications
The applications and analytics work streams are intrinsically linked as computing
platforms and operating systems deployed in the city must be based on
standards derived models with the potential for evolution and a clearly defined
technology ‘roadmap’.
Utilising this approach third party developers and manufacturers will be
encouraged to produce new system components and functional technologies to
further enhance the city’s operations.



•

•
•
•
•

•

•
Distribution of SMART City Applications via a Common Telecom Infrastructure

Conclusion
SMART city infrastructure will enable an increasingly ‘intelligent’ portfolio of
security, transport, utility plant and building management solutions to be
deployed within metropolitan and urban environments going forward.
These systems will traverse dedicated infrastructure - physical, wireless and
virtual which may or may not be owned by the city but should always be
designed to benefit the community and population of the city.
It is hoped this high level document may serve as the basis of a framework for
communities and city planners seeking to initiate deployment of SMART city
solutions by highlighting strategic areas for consideration, namely:

•

•

•

•

12

Development of a series of long term aspirational objectives that serve as
the guiding principles for the deployment of SMART city infrastructure and
technology within the public realm;
Development of a strategy that treats the interface between the City and its
operating and commercial partners as enterprise architecture;
Identification of a suitable ‘open’ architecture framework;
Engagement of a suitably experienced architect to map/design the
relationships and systems required to support the SMART city;
Recognition of the importance of the data communications infrastructure to
SMART city strategy by reserving above and below ground space to
accommodate network topology going forward;
Review the investment that will be required and the revenue generation
that maybe available to the community through various iterations of ‘open’
ICT networks;
The ubiquitous deployment of wired and wireless intelligent devices used to
automate day to day management of the city and its resources including
utility infrastructures, municipal building management systems, transport
systems and the operation of the public realm;
Open, standards based systems deployed and aligned with suitably robust
architectural frameworks in order to manage convergence whilst avoiding
procuring proprietary systems;
Converging systems increasing functionality provided by existing platforms
whilst simultaneously providing opportunities for reduction in capital and
operating expenditure;
City operating systems and middleware platforms implemented to facilitate
system aggregation and integration in order to ensure the smooth running
and longevity of the SMART city;
Third party developers and manufacturers encouraged to produce new
system components and functional technologies to further enhance the
city’s operations;


Appendix


13



14

SMART CITIES and CITY 2.0
LinkedIn Initial Comment

22/03/2013
Group Members Response

Paul Goff - 5 key areas to SMART city deployment
focusing on practical deployment and implementation:
Piergiorgio Roveda, Will Winn and 3 others like this
Enterprise Architecture – develop an approach and
framework that will enable the municipal client to resolve
issues of governance, tenure, commercial impetus along
with a roadmap for development and clearly defined
objectives by placing the city at the centre of the
architecture;

Log of LinkedIn Discussions
Instigated by Buro Happold Focussing on Practical
Deployment of SMART City Infrastructure

Data Communications & Infrastructure – Layers 1 & 2 of
the OSI model, physical infrastructure and network
topology, reservation of above and below ground space,
allocation of suitable equipment rooms and space,
concept through to detailed design of local access,
campus and or Metro networks;
Controls & City Operating Platform Integration –
Identifying suitable city operating platforms/ middleware
and integrating multiple data streams from sensor,
control and supervisory layers, including feeds to 3rd
parties;
Analytics – the ‘Big Data’ piece, collation and processing
of city wide data, macro and micro level, indentify and
specify systems used to store, manage and manipulate
this data, who owns this data – how can it best benefit
the city and its population;
Applications - Top down approach incorporating best of
breed and emerging bespoke 3rd party applications,
functional technologies etc. the longevity of the system
will be reliant on ensuring third parties are attracted/
encouraged to develop new applications;
High level but what do you think?

Secondary comment



Paul Goff - Practical deployment of a hypothetical (but
very soon to be realised) SMART city operating platform,
thoughts appreciated on the following:
A city operating platform implemented as a distributed
architecture with nodes deployed across the public
realm and co located with PON points of presence
(PoP’s) and fibre distribution hubs (FDH) to enable said
nodes to aggregate data collated from residents
dwellings by piggy backing connectivity off the passive
fibre network. In the worst case scenario these nodes
may even need to be located in street side cabinets.
What are the implications for physical interconnection to
the FTTH infrastructure e.g. presumably there will be
issues for conflicting operating wavelengths for active
equipment?
At the PoP, I guess the introduction of WDM equipment
would enable the city operating platform node to share
feeder cable with the OLT but what on earth would
happen at the street side splitter?
Would physical presentation be an issue particularly if
the city operating node was located in a street side
cabinet alongside the FDH – is there a solution
manufactured today that can resolve this issue?
Finally what would happen in a typical residential end
user premise e.g. a SMART home, data aggregator will
need to share drop cable connectivity with an existing
ONU – thoughts again on physical presentation and a
manufacturer who produces appropriate equipment
today?
I plan to pose the same set of questions in the FTTX
group.

22/03/2013

Harish Magan likes this

Secondary comment

15


22/03/2013

Paul Goff - Off the shelf City Operating System?
Does anyone know of an organisation that can deliver
an off the shelf, non-proprietary & commercially viable
city operating system?
Michael Gould • why non-proprietary per se? Seems some
people add this to the list just because... The city's cars,
computers, telephones, and much of its software is proprietary.
does that in itself make it better, worse, more/less stable or
reliable? Threre are muliple business models for creating,
providing, and maintaining software systems. Most orgs look for
a whole package that works for them, helps them solve
problems, and produces a positive return on investment.

Secondary comment
Paul Goff • Hi Michael - agreed, I guess
I was referring more to non-proprietary
interfaces between systems e.g. if a
vendor develops a nice, new functional
technology and associated control it
would be great to be able to plug that
control into an off the shelf package
used to manage and operate the
cityscape.
Current practice dictates purchasing an
all-encompassing system from one
vendor or from a group of vendors who
have been smart enough to form their
own proprietary club - in my view a
standards based approach would
resolve this but is there an organisation
with a suitable off the shelf package to
blaze a trail?
I am aware of some of the bespoke
approaches by some of the bigger
players with their own consulting arms
but that is a frightening prospect for a
lot of aspiring municipalities and city
developers.




22/03/2013

Secondary comment

16





22/03/2013

Cesar Garcia • @Michael I imagine it's just to prevent vendor
lock-in. Given citizens are paying taxes for it, it would make
complete sense to go for an option that is interoperable,
standards based, instead of a proprietary one.
While most orgs look for something that works, as public
bodies, they should check this issue to make the solution
future-proof. Office doc format comes to my mind. Big pain for
interoperability with other OS, every version of Office renders it
differently, vendor swapping it for docx with product transition.
Is that what we want for cities?

Prof. Peter Sachsenmeier • Paul, tell me when you find it.... :-)

Secondary comment




22/03/2013

Secondary comment

17





22/03/2013

Michael Gould • @Paul, good to see you focus on interoperable
interfaces...which provide wider access to and exploitation of
proprietary software. The P word is a legal distinction not a kind
of software per se,
@Cesar, on "lock-in" I think we can all think of free software
solutions that are controlled by a small core of programmers
who have their users by the cojones...but, again, access via
APIs and open interfaces is normally the solution.
As to future proofing, I am surprised to see that mentioned in a
tech-related forum, since technology DOES and WILL change
constantly, so trying to protect against it is fruitless. Therefore
any solution you choose as an option to MS-Office will be (just
as) irrelevant in a few years anyway. Cities will need to react to
change as well; there will be no timeless silver bullet solution
for them on the tech side.
Finally, @Paul, I wish you luck in your search for a single
COTS solution for the City OS. I suspect that for a long while it
will remain a hotchpotch of tech solutions, some loosely and
some tightly coupled, simply because the city is a diverse and
evolving creature. (Case in point: no smart cities vendor/pundit
saw citizen social media coming! even when all our kids started
texting all the time a decade ago.)
cheers,
MG

Keean Schupke • Hi, Just joined this group, and would be
interested to know what you mean by a city 'operating system'?
I agree that focusing on open standards for interfaces is key,
but this has to avoid vendor extensions that are not
documented. What about the "Amazon" approach - Everything
is a web-service. If each proprietary vendor system (say BMS,
etc) provides a Web Service API (say SOAP or REST), then
integration applications can be written as web-services
themselves. You can write mobile-apps, or web-apps to access
the smart city services directly, and you enable a market in new
third party integration apps.

Secondary comment
Paul Goff • Hi Keean, loosely I would
describe a city operating system as the
integration of city wide information
technology systems e.g. linking
together computing systems,
applications and infrastructure
physically and functionally to act as a
coordinated whole.
I would expect this integration to
provide real time control capability at a
micro and macro level, offer an
integrated platform for multiple types of
control and sensor/actuator, deliver
supervisory and analytical capability at
an industrial scale for large quantities
of historical data and finally provide
data and control capability to
applications and functional technology
developed by 3rd parties.
Definitely agree with your comments,
ensuring that third parties are
encouraged to develop apps and new
system components would be the key
to deploying a system with longevity.




22/03/2013

Secondary comment
Paul Goff • Thanks Paul - perhaps it
would have been more useful for me to
propose a stack based scenario for
example the interface between a
supervisory and controls layer and a
city operating system, anyway be good
to get your thoughts.

Paul Goff
'Open' interfaces on city operating systems, thoughts
on enforcing an open approach, are there existing
standards for these largely bespoke platforms, is it
better to use specs. from controls vendors?
paul jenkins • Paul, I think there are two aspects to this, one
being IT standards and one being data standards. Open
standards from the IT point of view consist of the "how" of
interfaces. Then there is the "what" in terms of information.
Both of these aspects can be subject to standards.
Typically, the "how" will be addressed by open IT standards
such as web services and the "what" is addressed by industry
standards in terms of information structure. We see this in other
industries such as banking, insurance, healthcare etc.
In the IT industry these issues have been dealt with for years
through the use of integration products, canonical data models
etc.
Will continue off-line to avoid clogging the comment trail !
Cheers,
Paul
paul jenkins • Paul, that is exactly what I am doing some work
on as a follow on action from a meeting with one of the solution
providers. Building up a stack view to go from devices up to
user applications delivery. Watch this space!

18


22/03/2013

Secondary comment
Paul Goff • Thanks Dave, really
interesting particularly the case studies
in the municipal ICT architectures
document.

Paul Goff - Is TOGAF a suitable framework to employ in
order to overcome issues of tenure and governance
when developing SMART city strategy for municipal
clients?

Dave Fitch • Yes. See
http://smartcities.info/files/Creating%20Municipal%20ICT%20Ar
chitectures%20-%20Smart%20Cities.pdf and
http://smartcities.info/files/ICT_architecture_supporting_service
_delivery_in_Smart_Cities.pdf for more information/examples.

Framework for SMART City Deployment V1.0

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Framework for SMART City Deployment V1.0

Similar to Framework for SMART City Deployment V1.0 (20)

Recently uploaded

Recently uploaded (20)

Framework for SMART City Deployment V1.0