Actions

CityWeb

From Modelado Foundation

Revision as of 00:48, April 24, 2017 by imported>Niveditasinghvi

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 PCAST Report and CityWeb

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

  • 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."

What does that mean for us?

Software plays a central role in the content of these solutions. To implement the CityWeb abstraction, a key pillar will be a software development kit targeted to Smart City solutions (a CitySDK), and the presence of a strong open source community that generates and assists in the dissemination of that CitySDK along with knowledge, expertise, and documentation. To that end, we propose below a CitySDK project, consisting of a software development kit for Smart City solutions, supported by an open source community with the aim of driving information-sharing and smart urban development, as described below.


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 created and maintained by an open source development community. The goal of both is to enable, assist and make more efficient the development of Smart City applications. Equally important is the requirement of 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 and the community:

Key Attributes

  • Support for open standards, with a strong preference for commonly-accepted open APIs whenever possible. We encourage not only the adoption of open industry standards whenever 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.
  • In order to grow and sustain a successful open source project, we hope to encourage the usual best practices with respect to open source development projects, namely the following:
    • Support under open source sanctioned licenses (preferably Apache v2 License, or any commonly-used Open Source Initiative(OSI)-approved open source license)
    • Copyrights retained by the authors
    • Open and transparent governance (to start with, simply having an open merit-based maintainer structure)
    • Open development processes (public communication via IRC, mailing lists or forums, public patch submission and approvals, public development discussion)
    • Inclusive principles and encouraging participants from all sectors (commercial, public sector, research, academia)

Detailed Steps

Described in this section are a list of steps and milestones that would be typical to rollout such a project.


STEPS COMMENTS
Establish infrastructure for development Github source tree, development and test systems, mailing lists, IRC, wiki, Slack, etc.
Establish central repository, website Will require hosted IT services
Establish membership access, submission channels, archives
Solicit contributions of documents, reports, project write-ups, and other know-how Populate the knowledge database
Establish open source development community Leverage open source skills, experience, knowledge, build and share software
Communicate, advocate, collaborate, educate on CitySDK
Maintain and sustain community

Components and Resources Required

Although this project aims to be lightweight and mostly volunteer-driven, there are some resources that will be required for the project. Primarily, the project's explicit needs are:

  • Computing resources to test, build, archive code (systems, sensors, software)
  • Hosted Website, Cloud presence (instantiation and continued support)
  • Open Data Archive & Software Analytics (storage and software)
  • Participants (volunteering time, effort, skills)


Goals of the CitySDK proposal

As described above, the CitySDK project is motivated by the need to assist and enable the development of Smart City solutions, with interoperability and information-sharing being key requirements. We also envision the following benefits arising out of a successful implementation of the CitySDK proposal:

  • The CitySDK project will act as a resource for the projects executed under the GCTC SAC Summit umbrella. As described in the PCAST report's CityWeb features [1], one of the CitySDK's goals will be to act as a central repository for information. The projects under the GCTC umbrella (indeed, any project funded by the US government related to Smart Cities) could archive their project reports, blueprints, other documentation, best practices and lessons learnt here. The availability of a central repository of Smart City knowledge and experience, code and tools will help newer projects and other cities get engaged quickly. It will also serve as a resource for the other SuperCluster Action Summits.
  • A large number of urban areas are engaging in Smart City development projects. Most, if not all, are performing their own investigation and research from scratch to determine what needs to be done, what can be done, what potential solutions are available and how to go about implementing them. At present, there does not exist a repository of information on what has been tried, what has worked, what has not worked. Nor is there a handy catalog that one can peruse to gather information on vendors, suppliers, products and solutions. Having such an easily accessible, central store of knowledge and experience would save time and get them going faster, and make available options that might not have been visible otherwise.
  • The CitySDK, along with its information repository, is also enhanced by an open source development community, bringing together best practices and subject matter experts. Access to SMEs in the Smart Cities technology space will be a valuable asset.
  • One of the risks of selecting a vendor and solution is the uncertainty of the future of the technology, especially when no single standard or de-facto market leader is available. When a large number of competing and non-interoperable solutions are available, it's always a risk that the one selected will fail in the marketplace and eventually the technology will require replacement prematurely. The push for open APIs, industry-accepted standards and interoperability gains traction as the number of such cooperating organizations, cities and developers grow.
  • Having common APIs and standards makes it easier for public sector agencies and organizations to make their data public and consumable by 3rd party developers. It also makes it easier for commercial players to interact with each other and build solutions for Smart Cities that benefit their customers and residents.


Next Steps and Conclusions

The above proposal for a CitySDK and Information Archive follows through on the ideas presented in the PCAST report [1] on the Future of Technology and Cities. It also tries to build upon the Smart City Initiative and GCTC SAC mission. In order to get started on this proposal, we list below the next steps to be taken.

  • Identify collaborators, contributors, users
    • Identify partners and the right skills who would be willing to contribute and participate in open source code development of CitySDK
    • Identify other users and resources that would be valuable to the CitySDK
    • Identify collaborators who could provide infrastructure resources to the CitySDK
  • Get buy-in from partners, collaborators on a plan for the project
    • Get support for a long-term, sustained effort to successfully build such a project and deliver value
  • Publish a plan to go forward with the project
    • Develop a plan to extend to and involve GCTC Supercluster projects as they go forward


References

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

Retrieved from "https://modelado.org/index.php?title=CityWeb&oldid=5076"