Potential use case for discussion – Street Light Automation Group Name: WG1/2 Source: Cisco Meeting Date: Joint-REQ-ARC-WGs-call Agenda Item: Use cases.

Slides:



Advertisements
Similar presentations
Demand Response: The Challenges of Integration in a Total Resource Plan Demand Response: The Challenges of Integration in a Total Resource Plan Howard.
Advertisements

Introduction Build and impact metric data provided by the SGIG recipients convey the type and extent of technology deployment, as well as its effect on.
Smart lighting control Done by : Haya Salah Esraa Nabulsi Eman Dwikat Under the supervision of: Dr. Kamil Subhi.
Ver 1,12/09/2012Kode :CIA-230 Anal-Perc.SistemFASILKOM PERTEMUAN-4 Chapter 4. Use Case Analysis.
Presented by: Sheekha Khetan. Mobile Crowdsensing - individuals with sensing and computing devices collectively share information to measure and map phenomena.
Connected Vehicles AASHTO Annual Meeting | October 17, 2013 | Denver, CO Mike Cammisa Director, Safety Association of Global Automakers.
Driver Safety.
산업 및 시스템 공학과 통신시스템 및 인터넷보안연구실 김효원 Optimizing Tree Reconfiguration for Mobile Target Tracking in Sensor Networks Wensheng Zhang and Guohong Cao.
Revisions to Part 8 – Traffic Control for Railroad and LRT Grade Crossings.
DRIVING IN URBAN TRAFFIC
Visual Traffic Simulation Thomas Fotherby. Objective To visualise traffic flow. –Using 2D animated graphics –Using simple models of microscopic traffic.
Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:
TRANSPORT MODELLING Lecture 4 TRANSPORT MODELLING Lecture 4 26-Sep-08 Transport Modelling Microsimulation Software.
Work Zone Safety It Starts With YOU!!. 2 BOOK 7 What is NEW??? IMSA TECHNICAL EXPO October, 2014 Dave Edwards.
Traffic Engineering Traffic Control Devices. Traffic Control Traffic engineers do not have any control over individual drivers need to develop devices.
Measure 26 Strategic Traffic Management Katerina Oktabcova Usti nad Labem Municipality.
1 SDOVerticals To Approach Overall Initial focus on, but not limited to: eHealth Smart Grid Transportation/Telematics Connected Home/Home Automation ARIB/TTC.
Traffic Control Officer for Civilians 15.0
Introduction Mobile Switch is a device which will be helpful to switch on and off any electrical/electronic devices through a SMS. The parameters of these.
Presented by: Chaitanya K. Sambhara Paper by: Maarten Ditzel, Caspar Lageweg, Johan Janssen, Arne Theil TNO Defence, Security and Safety, The Hague, The.
Electricity and Electrical Circuits Part 1 - Introduction
Page 1 January 2002 doc.: IEEE 802.RR-02/018A-d5 IEEE 802 IEEE 802 proposal relating to DFS and JPT5G proposal.
1 Paul Pisano FHWA, Team Leader Road Weather & Work Zone Management Weather and the Connected Vehicle Presentation at the Connected Vehicle Program Public.
Dixie Regional ITS Architecture Project Summary July 31, 2006.
Optimized M2M interworking with mobile networks Group Name: oneM2M REQ Source: Takanori Iwai, NEC, Meeting Date: Agenda.
Use case for discussion Smart Metering with Satellite Communications Group Name: WG#1 Source: Inmarsat Meeting Date: Joint-REQ-ARC-WGs-call Agenda Item:
The Science of Prediction Location Intelligence Conference April 4, 2006 How Next Generation Traffic Services Will Impact Business Dr. Oliver Downs, Chief.
Opportunities for ATSSA in ITS Mike Schagrin ITS Joint Program Office US Department of Transportion.
OneM2M-REQ R03 Proposed simple guidelines for writing use cases and requirements Group Name: oneM2M WG1 / WG2 Source: Joerg Swetina (NEC), Ataru.
Proposed Co-convened WG1/2 Objectives, Schedule, and Activities Group Name: TP#1 Source: Omar Elloumi (Alcatel-Lucent), Laurent Laporte (Sprint) Meeting.
Lockheed Martin Aeronautics Company Candidate Collaborative Projects for Net-Centric Application Michael F. Siok, PE Lockheed Martin Aeronautics Company.
Transportation and Transit Committee 4 December 2002 Albion Road Corridor Study.
Potential use case for discussion – Device Abstraction Group Name: WG1/2 Source: Alcatel-Lucent Meeting Date: Joint-REQ-ARC-WGs-call Agenda Item: Use cases.
Group Name: oneM2M WG1 Requirements Source: Phil Hawkes, Rapporteur “Benefits of oneM2M technology” TR,
Usage Scenarios for CSE Group Name: WG2(ARC-WG) Source: Shingo Meeting Date: Agenda Item: Message.
Advanced Controls and Sensors David G. Hansen. Advanced Controls and Sensors Planning Process.
Group Name: oneM2M WG1 Requirements Source: Phil Hawkes, Rapporteur “Benefits of oneM2M technology” TR,
CONTENTS: 1.Abstract. 2.Objective. 3.Block diagram. 4.Methodology. 5.Advantages and Disadvantages. 6.Applications. 7.Conclusion.
Transmission Customer Forum Operating Agreement Update Cheryl Johnson 9/21/06.
Student Name USN NO Guide Name H.O.D Name Name Of The College & Dept.
CONTENTS: 1.Abstract. 2.Objective. 3.Block diagram. 4.Methodology. 5.Advantages and Disadvantages. 6.Applications. 7.Conclusion.
Name Of The College & Dept
OneM2M Partnership Project. Contents Introduction Founding Partners Participation Scope & Objectives Structure Deliverables Contacts © 2013 oneM2M Partners.
Group Name: oneM2M WG1 Requirements Source: Phil Hawkes, Rapporteur “Benefits of oneM2M technology” TR,
Potential use case for discussion – Street Light Automation Group Name: WG1/2 Source: Cisco Meeting Date: Joint-REQ-ARC-WGs-call Agenda Item: Use cases.
Proposed Co-convened WG1/2 Objectives, Schedule, and Activities Group Name: TP#1 Source: Omar Elloumi (Alcatel-Lucent), Laurent Laporte (Sprint) Meeting.
On Multihop Communications For In-Vehicle Internet Access Based On a TDMA MAC Protocol Hassan Aboubakr Omar ∗, Weihua Zhuang ∗, and Li Li† ∗ Department.
Group Name: oneM2M WG1 Requirements Source: Phil Hawkes, Rapporteur “Benefits of oneM2M technology” TR,
Intelligent and Non-Intelligent Transportation Systems 32 Foundations of Technology Standard 18 Students will develop an understanding of and be able to.
Do Now Questions 1.What is the speed limit for school zones? 2.If you miss your exit on an expressway you should? 3.If you come to a multi-way stop at.
SunGuide SM Incident Management Concepts Robert Heller October 21, 2004.
Intersections.
Group Name: oneM2M WG1 Requirements Source: Phil Hawkes, Rapporteur “Benefits of oneM2M technology” TR,
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
DETECTION AND ASSESSMENT OF SAFETY PROBLEMS WITHIN ROAD TRANSPORT DECISION MAKING Prof. Dr. Nikolay Georgiev eng. Violina Velyova ‘Todor Kableshkov’ University.
DATEX Activity 6 Enhanced Usability
Systems Analysis and Design in a Changing World, Fourth Edition
Research Design and Methods (METHODOLOGY)
ESB Networks Market Release Meeting of the IGG, May 28th 2009
VEHICLE MANAGEMENT SYSTEM
Possible options of using DDS in oneM2M
Control Control Devices.

GSC Emergency Communications Task Force Report (GSC-EM TF)
Arduino based Seismic Sensor for Earthquake Detection and Response
TUGS Jason Higuchi && Julia Yefimenko && Raudel mayorga
Reinhard Scholl, GTSC-7 Chairman
Welcome to the New Smart City by TrafficCast…
Erasmus Intensive Program
Presentation transcript:

Potential use case for discussion – Street Light Automation Group Name: WG1/2 Source: Cisco Meeting Date: Joint-REQ-ARC-WGs-call Agenda Item: Use cases

Contents Background Description Source Actors Pre-conditions Triggers Normal Flow Alternate Flow Post-conditions High Level Illustration Potential requirements

Background Street Light Automation is part of the City Automation vertical industry segment Industry segment organisations: none known Industry segment standards: none known Deployed with varying functionality, in multiple countries Street Light Automation Goals – Improve public safety – Reduced energy consumption / CO2 emissions – Reduce maintenance activity Methods – Sensing and control – Communications – Analytics

Description – 10 sub-use cases A street light automation service provider, provides services to control the luminosity of each street light dependent upon: Local (street level) 1.Light sensors 2.Power quality sensors 3.Proximity sensors (civilian or emergency vehicles, pedestrians) Street light automation service provider operation center 4.Policies (regulatory & contractual) 5.Ambient light analytics (sunrise/sunset, weather, moonlight, etc.) 6.Predictive analytics (lights parts of streets predicted to be used, etc.) Communications received from other service providers 7.Traffic light service (emergency vehicle priority) 8.Emergency services (vehicle routing, police action, etc.) 9.Road maintenance service (closures and/or diversions) 10.Electricity service (power overload)

Source (as applicable) Cisco Systems – from public document research “Street Light Control” use case identified in ETSI TR Is this use case covered by other SDOs? – Need input from TIA TTA ATIS ARIB TTC CCSA

Actors (as applicable) Street light automation service provider aim is to adjust street light luminosity Traffic light service provider aim is to enhance their emergency vehicle service using street lighting Emergency services provider aim is to brightly Illuminate police action areas brightly Illuminate planned path of emergency vehicles Road maintenance service provider aim is to obtain extra street light signalling near closed roads Electricity service provider aim is to have electricity consumers reduce their load when an overload is declared

Pre-conditions (if any) See sub-case flows

Triggers (if any) See sub-case flows

Normal Flow (as applicable) See sub-case flows

Sub use case 1 - Local: Light sensors Summary: (no atomic action steps) Trigger: Detected light level moves below/above threshold Action: Increase/decrease luminosity in a set of street lights Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)Street lights message the Street light system that street light sensors have detected light level movement below/above threshold 2)Street light system informs the “street light operation centre” with the street light sensor information 3)“Street light operation centre” messages the Street light system with a street light control message to increase/decrease luminosity according to “street light operation centre” policy. 4)Optionally (normal case), if street lights receive a control command from the Street light system within some time, then, street lights increase/decrease luminosity in a set of street lights according to “street light operation centre” policy. 5)Optionally (alternative case), if street lights do not receive a control command from the Street light system within some time, then, street lights increase/decrease luminosity in a set of street lights, according to local policy Note that the terminology “policy” refers to a set of rules which may be dependent upon variables output from analytics algorithms.

Sub use case 2 - Local: Power quality sensors Summary: (no atomic action steps) Trigger: Detected input voltage level moves above/below threshold Action 1: Send alert message to electricity service provider Action 2: Decrease/increase energy applied to a set of street lights Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)Street lights message the Street light system that street light power sensors have detected input voltage level movement above/below threshold 2)Street light system informs the “street light operation centre” with the street light sensor information 3)“Street light operation centre” messages the Street light system with an alert message to “electricity service provider” according to “street light operation centre” policy. 4)Street light system informs “electricity service provider” of alert message. 5)“Street light operation centre” messages the Street light system with a street light control message to increase/decrease luminosity according to “street light operation centre” policy. 6)Optionally (normal case), if street lights receive a control command from the Street light system within some time, then, street lights increase/decrease luminosity in a set of street lights according to “street light operation centre” policy. 7)Optionally (alternative case), if street lights do not receive a control command from the Street light system within some time, then, street lights increase/decrease luminosity in a set of street lights, according to local policy

Sub use case 3 - Local: proximity sensors (civilian or emergency vehicles, pedestrians) Summary: (no atomic action steps) Trigger: Civilian or emergency vehicle or pedestrian detected entering/leaving street section Action: Increase/decrease luminosity in a set of street lights Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)Street lights message the Street light system that street light power sensors have detected civilian or emergency vehicle or pedestrian detected entering/leaving street section 2)Street light system informs the “street light operation centre” with the street light sensor information 3)“Street light operation centre” messages the Street light system with a control message to increase/decrease luminosity according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to increase/decrease luminosity according to “street light operation centre” policy. 5)Optionally (normal case), if street lights receive a control command from the Street light system within some time, then, street lights increase/decrease luminosity in a set of street lights according to “street light operation centre” policy. 6)Optionally (alternative case), if street lights do not receive a control command from the Street light system within some time, then, street lights increase/decrease luminosity in a set of street lights, according to local policy

Sub use case 4 - Operation centre: Policies (regulatory & contractual) Summary: (no atomic action steps) Trigger: SLA non-conformity for low intensity imminent Action: Increase luminosity in a set of street lights to keep within SLA Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)Street lights message the Street light system that street light power sensors have detected civilian or emergency vehicle detected entering street section 2)Street light system informs the “street light operation centre” with the street light sensor information 3)“Street light operation centre” messages the Street light system with a control message to increase/decrease luminosity according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to increase/decrease luminosity according to “street light operation centre” policy.

Sub use case 5 - Operation centre: Ambient light analytics (sunrise/sunset, weather, moonlight) Summary: (no atomic action steps) Trigger 5a: A band of rain moves across an area of street lights Action 5a: Increase/decrease luminosity in a rolling set of street lights Trigger 5b: Sunrise/sunset is predicted to occur area in 30 minutes Action 5b: Decrease/increase luminosity in a rolling set of street lights Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)The “street light operation centre” detects through analytics that (5a) a band of rain is moving across an area of street lights, or (5b) Sunrise/sunset is predicted to occur area in 30 minutes 2)“Street light operation centre” messages the Street light system with a street light control message to increase/decrease luminosity according to “street light operation centre” policy. 3)The Street light system messages the street lights to increase/decrease luminosity in a set of street lights according to “street light operation centre” policy.

Sub use case 6 - Operation centre: Predictive analytics (lights parts of streets predicted to be used) Summary: (no atomic action steps) Precondition: Vehicle paths are tracked via proximity sensors and a route model is generated Trigger: A vehicle enters a street section which has 85% probability of taking the next left turn Action: Increase luminosity on current street section ahead and also on street on next left Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)Street lights message the Street light system that street light power sensors have detected civilian or emergency vehicle entering street section 2)Street light system informs the “street light operation centre” with the street light sensor information 3)“Street light operation centre” messages the Street light system with a control message to increase/decrease luminosity according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to increase/decrease luminosity according to “street light operation centre” policy.

Sub use case 7 - From other service providers: Traffic light service input (emergency vehicle priority) Summary: (no atomic action steps) Trigger: An emergency vehicle is approaching a junction Action: Increase luminosity in street lights along streets leading away from junction Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)“Traffic light service provider” messages the Street light system that emergency vehicle approaching street junction from certain direction. 2)Street light system informs the “street light operation centre” with the street junction information 3)“Street light operation centre” messages the Street light system with a control message to increase luminosity according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to increase luminosity according to “street light operation centre” policy.

Sub use case 8 - From other service providers: Emergency services input (vehicle routing, police action) Summary: (no atomic action steps) Trigger 8a: An emergency vehicle route becomes active Action 8a: Increase luminosity in street lights along vehicle route Trigger 8b: An area is declared as having an active police action Action 8b: Increase luminosity in street lights within police action area Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)“Emergency services provider” messages the Street light system that (8a) emergency vehicle street route is active, or (8b) an area is declared as having an active police action 2)Street light system informs the “street light operation centre” with the street junction information 3)“Street light operation centre” messages the Street light system with a control message to increase luminosity according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to increase luminosity according to “street light operation centre” policy.

Sub use case 9 - From other service providers: Road maintenance service input (closures and/or diversions) Summary: (no atomic action steps) Trigger 9a: A road is closed Action 9a: Program a changing luminosity pattern in street lights near to closed road Trigger 9b: A route diversion is activated Action 9b: Program a changing luminosity pattern in street lights along the streets of the diversion Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)“Road Maintenance service provider” messages the Street light system that (9a) a road is closed, or (9b) an area is declared as having an active police action 2)Street light system informs the “street light operation centre” with the road maintenance information 3)“Street light operation centre” messages the Street light system with a control message to set lights to changing luminosity pattern according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to set lights to changing luminosity pattern according to “street light operation centre” policy.

Sub use case 10 - From other service providers: Electricity service input (power overload) Summary: (no atomic action steps) Trigger: A power overload situation is declared Action: Decrease luminosity in a set of street lights Detailed flow (no confirmation, etc. – actors in “quotes”, system under study in italics) 1)“Electricity service provider” messages the Street light system that (9a) that an overload condition exists across some area. 2)Street light system informs the “street light operation centre” with the overload condition information 3)“Street light operation centre” messages the Street light system with a control message to decrease luminosity according to “street light operation centre” policy. 4)Street light system messages the street lights with a street light control message to decrease luminosity according to “street light operation centre” policy.

Alternate Flow (if any) In the case of loss of communications, street lights have local policies which they obey

Post-conditions (if any) Street light luminosity or luminosity pattern is adjusted as needed

Street Light Automation Service Provider Traffic light Service Provider Electricity Service Provider Emergency Services Provider Road Maintenance Service Provider High Level Illustration (as applicable) Street light information system Emergency Services Provider Street Light Automation Service Provider Electricity Service Provider Road Maintenance Service Provider = actors Traffic light Service Provider

Potential requirements (as applicable) Generic (needed by two or more verticals or applications) 1.The M2M solution shall support the ability to collect M2M device information 2.The M2M solution shall support the ability to deliver collected M2M device information to M2M service providers 3.The M2M solution shall support the ability to accept control commands (for devices) from M2M service providers 4.The M2M solution shall support the ability to deliver control commands to M2M devices 5.The M2M solution shall support the ability to accept local (device) policy from M2M service providers 6.The M2M solution shall support the ability to deliver local (device) policy to M2M devices 7.The M2M solution shall support the ability to accept information from M2M service providers for purposes of communications among M2M service providers 8.The M2M solution shall support the ability to deliver information to M2M service providers for purposes of communications among M2M service providers. 9.The M2M solution shall support the ability to estimate the time period from when a device sent a message to the M2M solution until when it responded with a message to the device. Specific (to this vertical/use case)  None Note that the terminology “local” refers to the perspective of devices