Dear Jose Manuel, your formulation of Requirement (a) is better than mine. I will replace it. Dear all, if there are no objections, I will send an email containing the material to Omar, Herman, Enrico. I will do so at 15:00, so you still have some time to object :-) I hope you can all attend the teleconference at 17:00, and show solidarity! https://global.gotomeeting.com/join/785049565 best wishes Lindsay ________________________________________ Dr. Lindsay Frost, Chief Standardization Eng. frost at neclab.eu<mailto:frost at neclab.eu> Mobile +49.163.275.1734 NEC Laboratories Europe, Kurfürsten-Anlage 36, D-69115 Heidelberg, Germany. Reg. Headoffice: NEC Europe Ltd, VAT DE161569151 Athene, Odyssey Business Park, West End Road, London HA4 6QE, Reg. in England 2832014 From: JOSE MANUEL CANTERA FONSECA [mailto:josemanuel.canterafonseca at telefonica.com] Sent: Montag, 17. Oktober 2016 14:29 To: Lindsay Frost Cc: fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>; serge.raes at orange.com<mailto:serge.raes at orange.com>; gilles.privat at orange.com<mailto:gilles.privat at orange.com>; JUAN JOSE HIERRO SUREDA; Mulligan, Catherine E A; Martin Brynskov; Seppo Haataja; Franck Le Gall; CARLOS RALLI UCENDO Subject: Re: [Fiware-oasc-etsi] CIM ISG Use Cases for disclosure to ETSI - no changes and no veto received. Hi Lindsay, Thanks for putting this together. Wrt requirement a) does it mean that a CIM system must implement the MCA interfaces itself? My personal understanding of Friday discussions was that “a CIM system shall be able to store and offer contextual data describing oneM2M devices, including but not limited to, the end points that will allow an application to interact with them, particularly sending command requests”. Am I missing something? Thanks, best From: <fiware-oasc-etsi-bounces at lists.fiware.org<mailto:fiware-oasc-etsi-bounces at lists.fiware.org>> on behalf of Lindsay Frost <Lindsay.Frost at neclab.eu<mailto:Lindsay.Frost at neclab.eu>> Date: Monday 17 October 2016 at 14:03 To: JUAN JOSE HIERRO SUREDA <juanjose.hierro at telefonica.com<mailto:juanjose.hierro at telefonica.com>>, "Mulligan, Catherine E A" <c.mulligan at imperial.ac.uk<mailto:c.mulligan at imperial.ac.uk>>, "gilles.privat at orange.com<mailto:gilles.privat at orange.com>" <gilles.privat at orange.com<mailto:gilles.privat at orange.com>>, Franck Le Gall <franck.le-gall at eglobalmark.com<mailto:franck.le-gall at eglobalmark.com>>, "serge.raes at orange.com<mailto:serge.raes at orange.com>" <serge.raes at orange.com<mailto:serge.raes at orange.com>>, Martin Brynskov <martin.brynskov at oascities.org<mailto:martin.brynskov at oascities.org>>, CARLOS RALLI UCENDO <carlos.ralliucendo at telefonica.com<mailto:carlos.ralliucendo at telefonica.com>>, Seppo Haataja <seppo.haataja at oascities.org<mailto:seppo.haataja at oascities.org>> Cc: "fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>" <fiware-oasc-etsi at lists.fiware.org<mailto:fiware-oasc-etsi at lists.fiware.org>> Subject: [Fiware-oasc-etsi] CIM ISG Use Cases for disclosure to ETSI - no changes and no veto received. Dear all, after the teleconf discussions on Friday, and some inline comments in the file: https://docs.google.com/document/d/1b52-J8uKiaO8mjrU8Rutw1-CG7AfF1Pc9vlGV8avMbM/edit#<https://docs.google.com/document/d/1b52-J8uKiaO8mjrU8Rutw1-CG7AfF1Pc9vlGV8avMbM/edit> as agreed I updated a "Version 2" of the CIM Use Cases, which is appended into the same google-doc. Nobody commented yet, so if you want to veto something, or add something, better do it fast. For your convenience, I copy the text here: VERSION 2 of the DOCUMENT …. GOES HERE …. Context Information Management Use Cases 1. Introduction The main goal of this document is to describe a number of examples of using Context Information Management, with a focus on services, particularly services involving human end users, which would be difficult or impossible to support using existing IoT frameworks. The examples will also be used to establish broad requirements for such CIM systems and for their interoperation with IoT platforms such as from oneM2M. It must be emphasized that IoT platforms such as oneM2M are aimed at providing technical and semantic interoperability, not the contextural interoperability which is the subject of Context Information Management [2]: “A Machine-to-Machine Solution is a combination of devices, software and services that operate with little or no human interaction.” “The purpose of the [oneM2M] Partnership is to prepare, approve and maintain globally applicable Technical Specifications and Technical Reports related to access-independent M2M Solutions.” [and ] “Technical Specifications and Technical Reports for: […] Identification and naming of devices and applications; […] Information models and data management (including store and subscribe/notify functionality);” The figure below (from [1]) illustrates what happens when there is a lack of semantic interoperability: information is exchanged at a “technical” level (words are spoken/heard), but meaning is lost, semantic interoperability is lost. [.png] At a higher level, context Information exchange relies on proper semantic interoperability (which would allow e.g. discovery of the existence of “four-volt two-watt bulbs”) to enable services (such as purchasing) which use additional relevant context information (such as location, numbers, technology type, guarantee information, manufacturer information, etc) to enhance or enable a service. Reference [3] provides a list of over one hundred specifications aimed at achieving semantic and/or contextural information exchange, in a host of isolated/vertical application areas. This diversity has a well-recognized and huge cost in terms of delaying of introduction of new services, raising the cost of switching from one standard to another, legal and regulatory uncertainty, etc. 2. Summary of major CIM Features/Requirements Based on the CIM use cases in later parts of this document, some very general system requirements are summarised here //EDITOR NOTE: not complete// a) The CIM system shall be able to discover and query the status of identified IoT devices within a oneM2M subsystem. b) The CIM system shall be able to input, discover, manipulate and publish CIM-data which is completely independent of M2M or IoT devices. Examples of such sources are human inputs (e.g. text messages, uploaded images), open data information (e.g. population figures, vehicle registration databases), geographical and topological location systems (e.g. building information models, map data) c) The CIM system shall be able to define context information (aka attributes) such that specific defined information can be acquired using varied sources, e.g. IoT data, non-IoT data, combined sources which vary by site, time period, business relationship or other relationship. The CIM system shall be able to publish the context information without systems which consume the information needing to know the source(s) in order to use/interpret the context information. c) The CIM system, by logical extension of (b) and (c) above, shall be extensible in the way attributes are assigned to things, to allow context information for a thing to be re-used in different deployment scenarios. d) The CIM system shall be able to input results of logical reasoning (e.g. from an Autonomous Information system or some other predictive application) as part of the context information for things. e) The CIM system shall be able to process queries based on sets of things according to characteristics such as "is contained in", "is near to", “belongs to”, “changed status between times A and B” f) The CIM system shall be able to provide a list of all things with a combination of attributes (e.g .“list all buildings downtown which are too hot”. Note that the CIM system relies on an IoT system for some data and shall not manage connectivity to things or IoT sources; CIM queries are independent of real devices and how they are connected. 3. Example Use Cases 3.1 UC1: Rubbish Container is Full (non IoT) Besides the city’s systems to optimize garbage monitoring and collection, citizens may provide a second trustable source or even help covering areas where IoT has not yet been deployed due to economic restrictions. The idea is to produce stickers with bidi codes, a unique number and a phone number that are posed in every garbage container or even garbage bin in the streets. This way, citizens may easily use the city collaboration APP published by the city council (or a specific section within a broad collaboration tool). Just pointing to the sticker and making a picture within the App, an incidence is sent. The citizen may optionally help even more by selecting in a menu the kind of incident (vandalism, full container, abnormal smell or content, other, etc). Users not having an installed application may send an SMS to the published phone number with the unique number, both detailed in the sticker. The city council web may have also a section of incident reporting where the unique number and the type of incidence can be provided as input as well. In the future the application might be extended to report other kind of incidences, for instance, damaged seating at public parks, damaged traffic lights/signals, dangerous street/road conditions, etc. 3.2 UC2: Parking in the street (both IoT and App) A city often is divided into different parking areas (by district for instance). Each parking area includes different on-street parking zones and off-street parking sites. There may be near real time information about the occupancy of the different parking zones both in relative and absolute terms. At certain parking zones ground sensors could be deployed, linked to an IoT system, which allows to publish individually the status of each parking spot to context information attributes like “number of available parking spaces in West Street”. Off street parking sites might publish periodically on the number of available spots, by a gatekeeper tapping entry/exit data into an App. The number of data sources can be broad, as shown by the list below, but the actual context information retrieved by an application will be just “number of vacancies in West street”. * Ground sensors monitoring each parking spot * Park Meters providing information about the number of tickets sold and the validity timeframe for those tickets. * Cameras capable of detecting the presence of vehicles at certain áreas (on street or off street). * Information provided by connected cars themselves which are capable of notifying the place at which they are parked. * Municipality GIS System providing static, structural information about the different parking areas, zones and their characteristics. * Information reported by the owners of off street or private parking sites. A Developer can create an application which helps drivers to park in accordance with their preferences. Application does not need to deal with different sensors but with context information related to entities of interest. A central repository of context data, coming from different sources would be queried. The Application is isolated from the different sensing and estimation methods for parking availability. A city council may want to create a dashboard which allows to monitor parking status at different city áreas and to extract (over a period of months) key indicators which enable parking improvement in the city. The application dashboard is agnostic about the different sensing methods used. [ttps://lh5.googleusercontent.com/MrSuq0hl5fjaIwPQkGRxhfNAZ3y5ayhyEOaVnsOfiaD6ZtocOzVEqH6NfUU8OQKfUZr6uSw] (Figure adapted from EC Project XYZ, give copyright credit or link) UC3: SmartPort (CIM-enabled services) A port is a complex system (i.e. “a system of systems”) that is selling a service to its customers (the shipping companies): warehousing and trans-shipping. A CIM system could make those services faster and more efficient by retrieving key information about the port operations, schedules, delays and business rhythm. Most of the systems providing relevant information today are mobile/desktop web forms filled by the different operators working at the port and in some specific cases Apps tied to specific works. Harbour operations are already very carefully scheduled, weeks or months in advance, however coupling of expected (and actual) delivery data to information about warehouse capacity, number of cranes available for trans-shipping, etc, could squeeze improved speed from the system. Shorter freight-holding periods can translate into lower insurance premiums. Flow of loading confirmations could trigger notifications a day or more in advance to road-freight companies to be ready for pickups. Intelligent staggering of loading/unloading of lorries could reduce congestion at bottlenecks in the roads in the port or on the nearby highways, reducing wasted time/fuel in traffic jams. UC4: Public Bus (attributes are extensible) Information about public buses is more and more available to citizens on public websites or in Apps. The basic method is integration of the bus schedule and a city map to allow users to plan journeys. The context of each bus in the network is simply “last known location” and “schedule of stops”. This “static” information can be updated in more advanced systems by tracking the GPS location of the driver’s mobile-phone and updating the CIM context every few minutes. In more advanced systems, the context can include the occupancy status of the bus (50%, 70%, 90% etc) by text-message update from the driver. Some buses may be half-sized or could have good internal WiFi and this could be other attributes. Excessive temperature in the bus due to breakdown of cooling could be commented by the users, or else be input by a digital thermometer. Each extension of attributes to some/all busses shall be handled flexibly by the CIM, without changing of applicationss. 4. References [1] Folmer, Erwin, und Jac Verhoosel. “State of the Art on Semantic IS Standardization, Interoperability & uality, 20119.”, Accessed 19.09.2016 at http://doc.utwente.nl/76291/1/Folmer-SOTA_web.pdf [2] ‘oneM2M Partnership Agreement’, Published 22 April 2013. Accessed 16.10.2016 at http://www.onem2m.org/images/files/oneM2M_Partnership_Agreement.pdf [3] https://sites.google.com/site/erwinfolmeronsemanticstandards/list-of-semantic-standards -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20161018/35251e48/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 78640 bytes Desc: image001.jpg URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20161018/35251e48/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 326340 bytes Desc: image002.png URL: <https://lists.fiware.org/private/fiware-oasc-etsi/attachments/20161018/35251e48/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy