Actions

CityWeb: Difference between revisions

From Modelado Foundation

imported>Niveditasinghvi
No edit summary
imported>Niveditasinghvi
No edit summary
Line 23: Line 23:


==== IoT and Open Data Trends ====
==== IoT and Open Data Trends ====
Just what are these explosively popular trends, and why are they so hard to work with? For a start, let's consider the IoT space. Web and other Internet applications are fairly mature technologies, but such software has so far resided in devices intended for computing (computers, laptops), or in industrial machines designed for specific, dedicated purposes. As open source software (''e.g.'' Linux and middleware) has increasingly commoditized basic software, it's become cheaper and feasible to place computing software in embedded boards and components that live in everyday devices not normally designed for them (''e.g.'' lights, doors, roads, roofs...).  
Just what are these explosively popular trends, and why are they so hard to work with? For a start, let's consider the IoT space. Web and other Internet applications are fairly mature technologies, but such software has so far resided in devices intended for computing (computers, laptops), or in industrial machines designed for specific, dedicated purposes. As open source software (e.g. Linux and middleware) has increasingly commoditized basic software, it's become cheaper and feasible to place computing software in embedded boards and components that live in everyday devices not normally designed for them (e.g. lights, doors, roads, roofs...).  


The arrival and maturing of sensor technologies that give us powerful ways to measure and monitor our environment and objects has coalesced with the effort to share data of all sorts in the public domain and utilize it to improve our quality of life. Sensors and small embedded devices, however, are very different in their operating characteristics from typical computing devices. They are constrained by their size (very small), power characteristics (often running on battery, not electricity), and often need to be kept running with no downtime. There isn't sufficient memory or processing power available to run normal general-purpose software environments. There isn't a cooling unit available to ensure the device doesn't overheat. Hence IoT sensors, devices and other "constrained" hardware require specialized protocols and software to be able to operate in such environments(low power, low memory, slower processing, long use-case, less serviceability).  
The arrival and maturing of sensor technologies that give us powerful ways to measure and monitor our environment and objects has coalesced with the effort to share data of all sorts in the public domain and utilize it to improve our quality of life. Sensors and small embedded devices, however, are very different in their operating characteristics from typical computing devices. They are constrained by their size (very small), power characteristics (often running on battery, not electricity), and often need to be kept running with no downtime. There isn't sufficient memory or processing power available to run normal general-purpose software environments. There isn't a cooling unit available to ensure the device doesn't overheat. Hence IoT sensors, devices and other "constrained" hardware require specialized protocols and software to be able to operate in such environments(low power, low memory, slower processing, long use-case, less serviceability).  
Line 88: Line 88:


== CitySDK Proposal ==
== CitySDK Proposal ==
Provide a high-level overview of a proposed CitySDK project and community.  Briefly describe the two primary elements of such a proposed – technical components and common APIs along with a vibrant, sustainable open source development community.
We propose a "CitySDK" project, which will be an open source software development kit developed by an open source development community.  The goal of both is to enable, assist and make more efficient the development of Smart City applications. As important will be to enable interoperability, and thus the support and development of common, open APIs and standards will be an important component of the project.


==== Technical Elements ====
We describe below some of the facets of the project.
Describe the technical elements of the proposal
 
*Vendor & HW agnostic software development toolkits
* Support for open standards, commonly-accepted open APIs where possible. We encourage not only the adoption of open industry standards wherever possible, but the development and implementation of support for such APIs. This can potentially mean participation in industry consortium groups which are developing such APIs, and contributing to their development.
*Support for common APIs
* We expect that the project will be hardware and platform agnostic, and the usual limitations of resources and logistics will be the determining factor in limiting support. Recommended would be a practical approach in selecting a few common options (e.g. programming language support, security mechanisms) which would cover the vast majority of use cases.
*Best practice white papers & SME access
* In addition to code libraries which provide helper functions or install support or an interface, we expect to also include a listing of recommended standards and APIs (even if no code is supplied).
*Github tooling
* Another non-code component will be documentation on best practices, research studies, and case studies and user experiences. One of the CityWeb goals was to facilitate the sharing of knowledge and experience across cities and projects and individuals. We anticipate encouraging the contributions of such knowledge from various sources in the public sector and industry partners.
*Sample guides
* We anticipate that Github infrastructure will be used to host the open source project. This includes using its Issue Tracker for bug tracking and its Pull Requests Feature for code submission mechanisms. 
*Packaging and delivery   


==== Development Community ====
Describe the community elements of the proposal
*Community constituents – active, participating members from broad constituent topics:
**Civic
**Commercial
**Academic
**Individual
*Open, transparent governance model
*Open source licensing and copyright retention (by participants)
*Best practices re modern open source communities
*Growing and sustaining an active community
*Naming – leverage of and differentiation to other “CitySDK” projects


== Goals of the CitySDK proposal ==
== Goals of the CitySDK proposal ==

Revision as of 03:02, April 2, 2017

This page is where the CitySDK chapter of the GCTC Transportation Supercluster Report will be written. For questions, comments, concerns or any other matters concerning this chapter of the GCTC report, please contact Daniel Frye (daniel.frye@urban.systems) or Nivedita Singhvi (niveditasinghvi@gmail.com). Any member of the GCTC Transportation SuperCluster is welcome to add or refine content in this report - just remember that your contributions will be edited by others over time as is normal in all crowd-sourced wiki material.


Document below:

___________________________________________________________________________________________________________________________________________________________

CitySDK - Supporting Smart City Application Development

Abstract

Writing "Smart City" applications is hard. Often, the software and tooling environment is proprietary and the resulting applications fail to interoperate with applications developed elsewhere. It can also be expensive due to a lack of in-house knowledge, skills and tools for such software. Having an open source Software Development Kit (SDK) that provides libraries, tools and common APIs could be valuable in addressing this problem. It would make it easier, cheaper and faster to develop, deploy and sustain Smart City applications worldwide. Having common APIs would make it cost-efficient and feasible to share and exploit open data in order to provide a richer, more user-friendly and more efficient digital experience.

There is an understandable hesitation in adopting APIs or standards that are pushed forward by commercial, proprietary vendors. Even if the API is open, the code supporting it often is not, and locks the consumer into the ecosystem of the commercial vendor, without the ability to interoperate with others. The vertical stack supporting such alternatives only results in the use case or application sector getting siloed into fragmented ecosystems. There are significant cost and adoption advantages when APIs are not only open but backed by open source communities. Leveraging such available resources (or getting them to cooperate with each other) would be valuable. It would also align with the Federal initiative for a "City Web", which encourages the adoption of common and proven approaches to the Smart City mission.


Introduction

Technology becomes more pervasive everyday, and cheaper, faster and easier to use. We expect more from it with every new generation. Two significant technology trends, namely Internet of Things (IoT) and Open Data, are promising innovation and change at an even greater pace than the usual rapid-fire deployment and adoption of technology. Federal Government initiatives pushing standards requiring compliance as well as increased funding in Smart Cities, Transportation, Grid, Energy among others which seek to exploit these trends are driving the need for greater software development in this space. With IoT and Open Data, it is becoming increasingly possible to build complex, interoperable software ecosystems that provide us with a richer, more time-efficient, cost-efficient, more energy-efficient and human-friendly digital quality of life.

However, the cost to develop, deploy and maintain these complex technology projects isn't getting correspondingly cheaper or easier. The burden of achieving these goals is still difficult for those in the public sector, academia, or even commercial organizations who might not have deep emerging technology skills.

IoT and Open Data Trends

Just what are these explosively popular trends, and why are they so hard to work with? For a start, let's consider the IoT space. Web and other Internet applications are fairly mature technologies, but such software has so far resided in devices intended for computing (computers, laptops), or in industrial machines designed for specific, dedicated purposes. As open source software (e.g. Linux and middleware) has increasingly commoditized basic software, it's become cheaper and feasible to place computing software in embedded boards and components that live in everyday devices not normally designed for them (e.g. lights, doors, roads, roofs...).

The arrival and maturing of sensor technologies that give us powerful ways to measure and monitor our environment and objects has coalesced with the effort to share data of all sorts in the public domain and utilize it to improve our quality of life. Sensors and small embedded devices, however, are very different in their operating characteristics from typical computing devices. They are constrained by their size (very small), power characteristics (often running on battery, not electricity), and often need to be kept running with no downtime. There isn't sufficient memory or processing power available to run normal general-purpose software environments. There isn't a cooling unit available to ensure the device doesn't overheat. Hence IoT sensors, devices and other "constrained" hardware require specialized protocols and software to be able to operate in such environments(low power, low memory, slower processing, long use-case, less serviceability).

Solutions implementing such protocols for IoT are offered by Google, Apple, Samsung, GE, Microsoft, and many other commercial and open organizations. However, they all have their own standard and API and devices written to work in one environment will not work in another. This lack of interoperability of IoT devices and sensors is leading to a serious fragmentation of services and infrastructure across all industries and domains. Why this is a bad thing for consumers is most easily seen with examples in the Smart Home area. A GE oven could only talk to a GE controller, a Samsung refrigerator would require a Samsung controller, and a Phillips light bulb would need a Phillips controller. Ideally, homeowners would like to be able to use a single controller or app to talk to all their devices at home, otherwise they would be simply overwhelmed with the number of apps and controllers they would need. They would also be locked into buying that vendor's products. For instance, if one light bulb failed, as all the other bulbs and their controller was from GE, talking GE APIs, the homeowner would be forced to buy a GE bulb that could talk to the controller, or face replacing all the bulbs and controller at once.

The importance of APIs and software components that can talk to each other impacts Open Data as well. Open Data as a concept has been around for several years, but of late has received greater attention and formal organizational support and definition. It has also been the focus of several Federal Government initiatives.

  • Wikipedia describes Open Data as the "...idea that some data should be freely available to everyone to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control."
  • The Open Data Institute defines Open Data simply as "data that anyone can access, use or share."
  • The Open Data Handbook, produced by the Open Knowledge Foundation, defines Open Data as "data that can be freely used, re-used and redistributed by anyone - subject only, at most, to the requirement to attribute and sharealike."
  • In the government sector, the 2013 Federal Government Open Data Policy requires newly-generated government data to be made available in open, machine-readable formats, while continuing to ensure privacy and security.


The President's Council of Advisors on Science and Technology (PCAST) issued a report in 2013 on "Technology and the Future of Cities", in which they identify the need for more effective approaches to data integration and sharing to solve problems in cities. They point out

  • Lack of universally accepted platforms and standards
  • City incentives that drive a focus on local issues
  • Incomplete awareness of available solutions
  • Lengthy procurement processes that are unsuitable for agile, iterative, technology-based solutions

and resulting

  • Uneven distribution of solutions
  • Idiosyncratic implementations
  • Rarely re-usable software for other cities
  • Expensive implementations
  • Disadvantages to smaller cities with fewer resources, less capacity for innovation who fall further behind in the digital quality of life offered to their residents.

"There are few private and no public mechanisms today to distribute the new knowledge and data associated with innovations comprehensively across the nation's cities. There is no "app store" specific to city applications..."

Hence they recommend the concept of a comprehensive information infrastructure for cities to use and share, the notion of a "city web", an information-sharing platform benefiting all cities, especially those with fewer resources. This would include information on solutions, best practices which have been tried and tested, and had the benefit of experience. "The goal of the City Web is to allow the accumulation and replication of urban solutions and associated data and technologies in ways that benefit cities with different sizes, different technological know-how, and different financial capabilities."

As software plays a central role in the content of these solutions, the presence of a strong open source community that generates and assists in the dissemination of open source solutions in the form of an SDK, applications, knowledge and expertise would be invaluable.

Chapter Outline

We describe in this chapter the concept of a "CitySDK", a software development kit and open source development community to address the needs mentioned above.

Scope and Definitions

Before we discuss an SDK for Smart City applications, we start with clarifying the term "Smart Cities."

Smart Cities

"Smart Cities" is a somewhat fuzzy concept with no single, widely-held definition. As this Smart Cities Definitions paper describes, there are many definitions associated with the term which has been used since the 1990s. For our purposes, we consider the following three closely related descriptions:

  • "Harrison et al. (2010), in an IBM corporate document, stated that the term “smart city” denotes an “instrumented, interconnected and intelligent city.” “Instrumented” refers to the capability of capturing and integrating live real-world data through the use of sensors, meters, appliances, personal devices, and other similar sensors. “Interconnected” means the integration of these data into a computing platform that allows the communication of such information among the various city services. “Intelligent” refers to the inclusion of complex analytics, modelling, optimization, and visualization services to make better operational decisions (Harrison et al., 2010)."
  • "Smart city as a high-tech intensive and advanced city that connects people, information and city elements using new technologies in order to create a sustainable, greener city, competitive and innovative commerce, and an increased life quality (Bakici et. al., 2012)"
  • "A smart city is an urban development vision to integrate multiple information and communication technology (ICT) and Internet of things (IoT) solutions in a secure fashion to manage a city's assets – the city's assets include, but are not limited to, local departments' information systems, schools, libraries, transportation systems, hospitals, power plants, water supply networks, waste management, law enforcement, and other community services. The goal of building a smart city is to improve quality of life by using urban informatics and technology to improve the efficiency of services and meet residents' needs. ICT allows city officials to interact directly with the community and the city infrastructure and to monitor what is happening in the city, how the city is evolving, and how to enable a better quality of life." -- From Wikipedia ("Smart City").

So what would the scope of such a broad term be? For our purposes, we consider the following horizontal sectors or domains, although they are by no means restricted tightly to these:

  • Smart Transit
  • Smart Transportation
  • Smart Wellness
  • Smart Buildings
  • Smart Infrastructure
  • Smart Energy
  • The availability and deployment of environmental technologies and information
  • The availability and deployment of weather information
  • The availability and deployment of technologies for stronger communities and public interaction
  • The availability and deployment of technologies for a richer software ecosystem for commercial and non-commercial goals

An SDK for Smart Cities

Although a large number of "horizontals" or different industries and domains fall into the scope of Smart Cities, it's helpful to note that there is a great deal of commonality in their vertical stacks. Many of the building blocks and functions needed for these applications (e.g. sensor reading, IoT core frameworks, network communication, security, messaging, database and data management, cloud interfaces, etc.) are the same across horizontal domains. Industry-specific software components for Smart City applications (such as support for the transit API GTFS) are also considered for inclusion in the scope of the CitySDK, where practical.

The intended scope of the CitySDK is the entire vertical stack for an application, from the core IoT framework, including support of IoT sensors, devices and platforms, to data processing and analytics, cloud storage and client application development. The emphasis will be on providing help for emerging technologies which do not yet have an established suite of helper applications and SDKs nor adequate documentation or skills prevalent in the ecosystem.

CitySDK Proposal

We propose a "CitySDK" project, which will be an open source software development kit developed by an open source development community. The goal of both is to enable, assist and make more efficient the development of Smart City applications. As important will be to enable interoperability, and thus the support and development of common, open APIs and standards will be an important component of the project.

We describe below some of the facets of the project.

  • Support for open standards, commonly-accepted open APIs where possible. We encourage not only the adoption of open industry standards wherever possible, but the development and implementation of support for such APIs. This can potentially mean participation in industry consortium groups which are developing such APIs, and contributing to their development.
  • We expect that the project will be hardware and platform agnostic, and the usual limitations of resources and logistics will be the determining factor in limiting support. Recommended would be a practical approach in selecting a few common options (e.g. programming language support, security mechanisms) which would cover the vast majority of use cases.
  • In addition to code libraries which provide helper functions or install support or an interface, we expect to also include a listing of recommended standards and APIs (even if no code is supplied).
  • Another non-code component will be documentation on best practices, research studies, and case studies and user experiences. One of the CityWeb goals was to facilitate the sharing of knowledge and experience across cities and projects and individuals. We anticipate encouraging the contributions of such knowledge from various sources in the public sector and industry partners.
  • We anticipate that Github infrastructure will be used to host the open source project. This includes using its Issue Tracker for bug tracking and its Pull Requests Feature for code submission mechanisms.


Goals of the CitySDK proposal

  • How the CitySDK will help the GCTC Transportation SuperCluster
  • How the CitySDK will help the other GCTC SuperClusters
  • How the CitySDK will help the overall community & marketplace
  • Break goals into time periods – next 12 months, next 24 months, next 36 months

Next Steps and Conclusions

  • Summarize the proposal
  • Detail proposed next steps
    • Gaining consensus
    • Building a critical mass
    • Launching a community/project
    • Initial activities
  • Cross-reference between the varied Supercluster activities and teams

References

Papers, talks, proposals, etc. that were major sources of inspiration