Advancing Smart Cities: IES-City Framework Overview
The International Technical Working Group on IES-City Framework, led by Dr. Martin Burns, is developing a reference framework for IoT-enabled Smart City technologies to streamline architectural designs and enhance interoperability. The group aims to create a common set of features for Smart Cities, allowing for incremental and composable development. Challenges such as divergent CPS/IoT technology and standards landscapes are being addressed through collaborative efforts. Letting the market decide and identifying Pivotal Points of Interoperability are key strategies to drive progress in Smart City deployments.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
International Technical Working Group on IES-City Framework: Overview June 15, 2016 Dr. Martin Burns Electronic Engineer Smart Grid and Cyber Physical Systems Program Engineering Laboratory National Institute of Standards and Technology 1
IoT-Enabled Smart City Framework Smart City technologies are being developed and deployed at a rapid pace. Many previous smart city deployments are custom solutions. A number of architectural design efforts are underway worldwide but have not yet converged. NIST and its partners are convening a public working group to distill a common set of architectural features from these architectural efforts and city stakeholders. Goal: A reference framework for the development incremental and composable Smart Cities 2
Overview The Challenge IES-City Framework Goals Pivotal Points of Interoperability Working Groups Let s go! 3
Times IES-City Framework Midpoint Workshop First Day June 15th Introduction and welcome Overview of project Application Framework 1. Review of charter, milestones, and deliverables 2. Approach and details 3. Results to date 4. Challenges Consensus PPI 1. Review of charter, milestones, and deliverables 2. Approach and details 3. Results to date 4. Challenges Deployed PPI 1. Review of charter, milestones, and deliverables 2. Approach and details 3. Results to date 4. Challenges Open Discussion Lunch Breakouts Recap first day Second half Day June 16th Open Discussion Breakouts / activities 8:00-8:15 8:15-8:45 8:45-9:30 9:30-10:15 10:15-11:00 11:00-12:00 12:00-13:00 13:00-16:30 16:30-17:00 8:00-9:00 9:00-12:00 4
The Challenge - Divergent CPS Standards Landscape Having all these different standards efforts practically ensures one thing: There s no way all of these devices will actually be able to all talk to each other until all this gets settled with either victory or a truce. Ina Fried, re/code, July 2014 6
Let the market decide! Graphic from: http://www.tvitaliaweb.tv/il-videoregistratore-compie-40-anni/ 7
Glass Half Full There are Pivotal Points of Interoperability that can be identified Identifying them will speed their understanding and reduce the distance to interoperability Help the market decide 8
IES-City Framework Goals Facilitate convergence and encourage harmonization among the many standards and consortia Produce a useful result in a short time certain Minimum complexity Actionable Reduce barriers to interoperability/integration Not pick winners and losers Attract collaborators from the key architecture and standards efforts so that they can bring results to their efforts The group will be open and free for participation by anyone, anywhere in the world and documents produced by the group will be available to anyone and at no-cost at the group web site 9
Working Plans Mar/Apr Workshops -- mutual awareness and kickoff working groups each working group develops parallel documents interacts by cross membership and identified liaison at monthly webinars get presentation from other groups June 15-16 Workshop -- presentations of parallel interim results compose/iterate composite solution groups interact more formally Fall 2016 composite draft review process and mature draft June 2017 final draft 10
Pivotal Points of Interoperability - PPI If you standardize everything, you freeze out innovation. If you standardize nothing, you get non-interoperable clusters that can t be easily integrated. The principle of Pivotal Points of Interoperability is to find consensus standardized interfaces that deal with composition of CPS without constraining innovation. 11
Pivotal Points of Interoperability (PPI) With Pivotal Points of Interoperability Independent technology deployments Minimize distance to interoperability e.g. Convert XML to JSON PPI e.g. REST APIs PPI e.g. TLS 1.2 Application Diversity PPI Potentially large distance to interoperability e.g. IPv6 address 12
How to Discover Consensus Architecture/ Framework B OneM2M Architecture/ Framework A FIWARE Possible Gaps Possible Extension Points Common Pivotal Points of Interoperability Process: 1) Transform architectures to CPS Framework normal form Transform deployments to CPS Framework normal form Compare results of 1) and 2) Broaden consensus of intersections Document Smart Cities Framework 2) 3) 4) 5) Union of Applications Architecture/ Framework C IOT-A 13
Public Working Groups Approaches Studying Technical Architectures Learning by Doing Studying Deployments Model Specifications Simplified Framework Working Group, Webinars and Analysis Working Group, Webinars and Analysis Working Group, Webinars and Analysis Mechanisms Analysis from Deployment IoT-Enabled Smart City Framework Review Specifications Application Framework Deployed PPI Consensus PPIs Breadth of Smart City/IoT Applications Readiness to Absorb Applications Self-assessment tools Super Action Clusters e.g. GCTC multiple domains, multiple technologies Analysis by case study Analyze technology suites according to CPS Framework Discover consensus PPI Document overlaps and gaps Results Participants: City leaders (includes CTOs, CIOs, Innovation Officers), Experts, Companies, Technical Stakeholders, Researchers 14
Working Group 1: Working Group 1: Application Frameworks Application Frameworks June 15, 2016 Vatsal Bhatt, USGBC Angelo Frascella, Arianna Brutti, ENEA
NIST Public Working Groups Technical Architectu res Learning by Doing Deployme nts Simplified Framework Model Specifications Workshop s and Analysis Workshop s and Analysis Convergen ce Action Cluster IoT-Enabled Smart City Framework Analysis from Deployment Review Specifications Consensus PPIs Consensus Deployed PPI Application Framework Device specifications Document overlaps and gaps Identify PPIs Find consensus standardized interfaces Review exemplar smart-city applications Summarize scope Develop structure of sub-domains Identify Metrics for evaluation Discover PPIs from existing Deployments Super Action Clusters e.g. GCTC Identify opportunities to develop more PPIs Participants: City CTOs, Experts, Companies, Technical Stakeholders,
WG1: Focus Areas Sub-groups and deliverables First draft of the WG1 report by Aug 1, 2016 Sub-Groups Deliverables List of applications and related metrics It contains both a framework (metrics + tool) for evaluating the breadth (elaborated on the basis of existing models) and the list of evaluated applications A framework for assessing City s Readiness A List of Metrics + a tool to Assess the Readiness of Cities to Absorb Smart City Applications (elaborated on the basis of existing maturity models) A Framework to Measure Benefits Metrics + tool for measuring benefits that can be derived from Assimilated Applications Ground-truthing (all sub- groups) Outcomes of 5-6 City Pilots on Benefits Framework and Readiness Metrics
Sub-Groups and Leads WG 1 Co-leads: Bhatt and Frascella+Brutti Sub-group 1: List of Applications and Metrics to Assess the Breadth (Interoperability of data is a catalyst) (Coordinator: Brutti) Sub-group 3: Metrics to Assess the Readiness (Open Data, Policy and Regulation) (Coordinators: Lamba and Mulquin) Sub-group 2: Framework to Measure Benefits (Business Models) (Coordinators: Marasso and Deschamps) Potential Pilot Cities (synergize w WGs 2 & 3?): Italy: Genoa, Bari U.S.: San Francisco, Los Angeles, Washington DC India: Ahmedabad, New Delhi, Mumbai, Vizag China: Weifang, Shanghai Africa, South America
Sub-group1: Applications Breadth of Smart City Application How many domains and subdomains are covered by an Application? A Smart City weaves together different domains. The understanding of application domains helps the decision makers to match it with the (unique) city set of needs But also what are its technological requirements, its cost, its level of integration? How to identify the list of applications to be analyzed? We have developed an initial list as seen in two recent workshops? GCTC Action Clusters (2015 and 2016) Others Certainly this list is the starting point. But how much should we expand it? OR keep it dynamic?
Urban Urban Applications Applications Assimilated few Smart City Application Frameworks (deployed and proposed) Captures the Breadth of Applications in Cities (dynamic in nature) PEOPLE CENTRIC
Smart City Applications Coverage A Sample of 100 Cities Source: Paolo Neirotti Politecnico di Torino, http://www.bestorino.com/SpC13/prematerials/2.pdf
Smart City Applications Coverage A Sample of 100 Cities Source: Paolo Neirotti Politecnico di Torino, http://www.bestorino.com/SpC13/prematerials/2.pdf
Source: Paolo Neirotti Politecnico di Torino, http://www.bestorino.com/SpC13/prematerials/2.pdf
Sub-group 2: Readiness Readiness of Cities to Absorb these Applications: A set of parameters for getting a common understanding of where a city is in terms of application needs, technological capabilities, political strategy, financial means paving the way to its getting smarter
How do we Assess Readiness of a City/Breadth of applications? Finding matching between City and Applications Business Model for 25
Aspect 1: Coverage/Breadth Based on Urban Applications: How many domains and subdomains are covered by the city integrative nature Note: if an application covers only a domain it is not strictly Smart City application (it falls in Ad Hoc stage) The readiness level of service delivery for each domain
Evaluating Readiness? What level do your application cover the following domains at? (0 = not covered; 1 = Basic Access to Services; 2 = 24x7 Services; 3 = Advanced Services; 4 = ICT Matured Services) Energy 0 ; 1; 2; 3; 4 o Supply Side Management 0; 1; Demand response programs 0; 1; Energy Simulation 0; 1; o Transportation 0 ; 1; 2; 3; 4 o Consumer
Aspect 2: Strategic Readiness IDC Smart City Maturity Model suggests two dimensions (Technology and Data) for an example; ad hoc, opportunistic, repeatable, managed, optimized http://az370354.vo.msecnd.net/publicsector/citynext/whitepapers/IDC%20Government%20Insights'%20Sm art%20City%20Maturity%20Model_IDC.pdf
IDC Smart City Maturity Model Strategic 29
Evaluate Maturity Stages-1 We need to define questions for evaluating the previous points Some inputs can come from: 1) BSI PAS 181 Understanding how much these cells are satisfied, for example, we could understand how much these interoperability levels has been reached http://www.bsigroup.com/en-GB/smart-cities/Smart-Cities-Standards- and-Publication/PAS-181-smart-cities-framework/
Evaluate Maturity Stages-2 We need to define questions for evaluating the previous points Some inputs can come from: Smart Cities Maturity Model and Self- Assessment Tool It is base on the IDC SC maturity model and define an auto- assessment questionnaire. This one does not automatically provide the evaluation of maturity parameters but some questions could be useful for our aims http://static1.squarespace.com/static/53c8d78be4b0c984e42f0c74/t/54d4ce1de4b0b33bf9d15278/1423232 541977/Smart+Cities+Maturity+Model+and+Self- Assessment+Tool_Guidance_January+2015_FINAL.pdf%20
Evaluate Maturity Stages-3 We need to define questions for evaluating the previous points Some inputs can come from: 3) Glasgow City Council Future Cities Programme Capabilities could help us in defining the elements to be inserted in the questionnaire
Aspect 3: Technologic maturity A first element in evaluating it is: in which stage of the SW life cycle is the application? If an application is still in its planning stage, is surely less mature of one already checked, for example Some technologies can be operating but old (considering the speed of technoloic evolution let s think, for example to Windows XP) We could add another stage, after operation : obsolete Figure from Smart Cities preliminary report ISO/IEC JTC 1
Sub-group 3: Framework to Measure Benefits of Smart Cities (Business Models) Cost cutting / Efficiency improvements; ICT investments relate to environmental quality or reduction in operating costs Value Addition; ICT investments create added value to public services and also generate positive externalities for the private sector Revenue Generation; ICT investments create new or increased revenue streams for private sector companies Source: C. Mulligan (2014) Imperial College (http://smartcitiesindex.gsma.com/community/index.php?resources/mobile-enabled-business-models-for- smart-cities-anew-perspective.7/
An Example of Benefits Matrix Source: Paolo Neirotti Politecnico di Torino, http://www.bestorino.com/SpC13/prematerials/2.pdf
Evolving a Business Model for Smart City Applications Benefits Matrix Source: C. Mulligan (2014) Imperial College (http://smartcitiesindex.gsma.com/community/inde x.php?resources/mobile-enabled-business-models- for-smart-cities-anew-perspective.7/
Source: C. Mulligan (2014) Imperial College (http://smartcitiesindex.gsma.com/community/inde x.php?resources/mobile-enabled-business-models- for-smart-cities-anew-perspective.7/
Source: C. Mulligan (2014) Imperial College (http://smartcitiesindex.gsma.com/community/index.php?r esources/mobile-enabled-business-models-for-smart-cities- anew-perspective.7/
Periodicity of Calls and Deliverables Calls: Every 2 weeks for each subgroup (Vatsal, Arianna and Angelo taking part in them) Subgroup leads will decide Every 3 weeks for the entire WG Deliverables: WG1 first draft of the report by Aug 1, 2016 Subgroup Deliverables will fit in this schedule
Challenges Ground-truthing Identify cities and test frameworks and tools 40
Thank You 41
Useful resources Web site: https://pages.nist.gov/smartcitiesarchitecture/ Our WG page: https://pages.nist.gov/smartcitiesarchitecture/community/applicationframe work/ Workshop documentation (Rome videos soon available): https://pages.nist.gov/smartcitiesarchitecture/library/ Web meetings: https://global.gotomeeting.com/join/404083029 phone:+1(408)650- 3123;404083029# Google drive folder: https://drive.google.com/drive/u/0/folders/0B8X_t7SvioZdd1ZncU13RGNa VW8
Working Group 2: Consensus PPI Working Group 2: Consensus PPI June 15, 20 Eric Simmon, NIST Stefano De Panfilis, Engineering
Public Working Groups Approaches Studying Technical Architectures Learning by Doing Studying Deployments Model Specifications Simplified Framework Working Group, Webinars and Analysis Working Group, Webinars and Analysis Working Group, Webinars and Analysis Mechanisms Analysis from Deployment Review Specifications IoT-Enabled Smart City Framework Consensus PPIs Deployed PPI Application Framework Device descriptions Document overlaps, gaps, and commonalities Identify PPIs Find consensus on harmonized interfaces Review exemplar smart- city applications Summarize scope Explore structure of sub- domains Identify metrics for evaluation Discover PPIs from existing Deployments Super Action Clusters e.g. GCTC Identify opportunities to develop more PPIs Results Participants: City leaders (includes CTOs, CIOs, Innovation Officers), Experts, Companies, Technical Stakeholders, Researchers 44
Public Working Groups Approaches Studying Technical Architectures Learning by Doing Studying Deployments Model Specifications Simplified Framework Working Group, Webinars and Analysis Working Group, Webinars and Analysis Working Group, Webinars and Analysis Mechanisms Analysis from Deployment Review Specifications IoT-Enabled Smart City Framework Consensus PPIs Deployed PPI Application Framework Device descriptions Document overlaps, gaps, and commonalities Identify PPIs Find consensus on harmonized interfaces Review exemplar smart- city applications Summarize scope Explore structure of sub- domains Identify metrics for evaluation Discover PPIs from existing Deployments Super Action Clusters e.g. GCTC Identify opportunities to develop more PPIs Results Participants: City leaders (includes CTOs, CIOs, Innovation Officers), Experts, Companies, Technical Stakeholders, Researchers 45
Subgroup: Consensus PPI The purpose of the Consensus PPI is to analyze: Existing exemplary Smart City Architecture and Internet of Things (IoT) descriptions including Standards, specifications Architectures, frameworks, conceptual models Platforms, protocols, environments Document their overlapping concerns such as functionality, data, timing, trustworthiness, etc Determine the common properties (solutions) specified in these overlapping concerns such as third party authentication, data encryption, time synchronization, data formats/ontologies Document these PPI and show the overlaps, gaps, and commonalities of choices made by the creators of the reviewed descriptions 46
IES-City Framework Goals Facilitate convergence and encourage harmonization among the many standards and consortia Produce a useful result in a short time certain Minimum complexity Actionable Reduce barriers to interoperability/integration Not pick winners and losers Attract collaborators from the key architecture and standards efforts so that they can bring results to their efforts The group will be open and free for participation by anyone, anywhere in the world and documents produced by the group will be available to anyone and at no-cost at the group web site
Consensus PPI CPSPWG concerns used to survey Architectures Concerns Properties (solutions) Architecture/ Framework A Architecture/ Framework B Possible Extension Points Common Pivotal Points of Interoperability Evaluate commonalities Pivotal points Extension points Gaps Architecture/ Framework C 48
CPSPWG List of Concerns actuation communication controllability functionality measurability monitorability performance physicalsensing uncertainty enterprise cost environment policy quality regulatory time to market human factors usability utility privacy reliability resilience safety security logical time managing timing and latency time synchronization time awareness time-interval and latency control data semantics identity operations on data relationship between data cross-domain physical context connectivity responsibility adaptability complexity constructivity discoverability deployability disposability engineerability maintainability operatability procureability producibility Facets Realization Conceptualizatio n Assurance Domains Functional Use Case, Requirements, Design / Produce / Test / Operate Argumentat ion, Claims, Evidence Business Manufacturing Aspects Human Trustworthines s Timing Transportation Activities Artifacts (propertie s) CPS Energy Data Boundaries Healthcare Composition Model of a CPS CPS Assurance Lifecycle . . . Domain 49
Stakeholder interaction CPSPWG Concerns 50
