FiWare

ETSI launches new Group on Context Information Management: the role of FIWARE

 APIs, Blog, FIWARE Foundation, GEs, GSMA, IoT, NGSI, OASC, SmartCities  Comments Off on ETSI launches new Group on Context Information Management: the role of FIWARE
Jan 132017
 
etsi-logo-620px

ETSIthe European Telecommunications Standards Institute, has announced the creation of a new Industry Specification Group on cross-sector Context Information Management (ISG CIM) for IoT-enabled Smart Cities and also other verticals including Smart Industry and Smart Agriculture.

The group will focus its activities on developing the specifications for a common Context Information Management (CIM) API, Data Publication platforms and standard Data Models, in order to achieve and improve cross-sector interoperalibilty for smart applications, with FIWARE NGSI as starting point. This blogpost offers further information on the role of FIWARE within the works of this new group.

As CIM API, the abstract NGSI 9 and 10 interface specifications from OMA will be the starting point, with a RESTful binding for the protocol based on the FIWARE NGSIv2 API developed under the FIWARE initiative. Specifications of this binding are expected to evolve in order to bring support to Linked Data using JSON-LD for representing the semantics of context information and their interrelationships.

As the press release by ETSI states, “Data without context are meaningless. Every sensor measurement, every entry in a database, every tweet sent and every webcam video watched has its own context.” Information will not be really useful without its own context; a context that should be published and made available with the data. The ISG CIM will specify open standards for the context information management layer that accesses and updates information coming from different sources (IoT networks and information systems) thus enabling to implement a context-aware behaviour for smart applications and extending its interoperability.

“With the rapid development of technologies such as Big Data, semantic web, complex workflow or autonomous decision making, the need for interoperable context information is becoming huge”, says Lindsay Frost, convenor of ETSI ISG CIM.

Lindsay Frost explains how the newly launched group will aid to overcome this problem: “The ISG CIM will specify protocols running ‘on top’ of IoT platforms and allowing exchange of data together with its context, this includes what is described by the data, what was measured, when, where, by what, the time of validity, ownership, and others. That will dramatically extend the interoperability of applications, helping smart cities to integrate their existing services and enable new third-party services.”



These will be the topics addressed by ISG CIM in order to ensure interoperability of independent SW implementations, including Open Source implementations,

  • Definition of a standard API for Context Information Management, enabling close to real-time update and access to information coming from many different sources (not only IoT). Such an API will enable applications to perform updates on context, register context providers which can be queried to get updates on context, query information on current and historic context information and subscribe for receiving notifications on context changes.
     
  • Specifications to be fulfilled by Data Publication Platforms supporting open data publication, data privacy and/or authorization of access, including enablers for multi-party access contracts will be considered.
     
  • Cross-domain Context Information Models that will deal with the definition of the models that are common to several of the domains being targeted, together with the meta models, definition languages and processes needed for the specification, curation, publication and evolution of Context Information Models will be defined and applied.
     
  • Smart Cities Information Models, where the specific models for the Smart Cities domain will be defined.
     
  • Information Models targeting other specific domains besides Smart Cities (for example but not limited to Smart Agrifood, Smart Industry) will also be considered.


The starting members of the new Industry Specification Group (ISG) are Easy Global Market, IMEC, NEC, Orange and Telefonica. ETSI has initiated this new group together with the organisation Open & Agile Smart Cities (OASC). Soon, the FIWARE Foundation will also join the ISG as new ETSI member.  Beyond the initial focus of Smart Cities, the cross-sector approach will be transferable to applications developed for other vertical domains, such as Smart Agriculture and Smart Industry. With the goal of interoperate and to re-use as much existing work and knowledge as possible, the group will work closely with the ETSI SmartM2M technical committee and with oneM2M, the global standards initiative for M2M and the IoT (Internet of Things) of which ETSI is a founding member.

The ISG CIM work responds to the EU’s rolling plan on ICT standardisation which is part of its Digital Single Market strategy.
The creation of this group leverages promising results of the collaboration between FIWARE and other relevant actors such as TM Forum or GSMA.


The first meeting of the ISG CIM is planned to take place at the ETSI premises in Sophia Antipolis, France, on 9-10 February 2017. Regarding FIWARE, by July 2017, a preliminary version of the CIM API is expected. The final version of its specifications will be developed by November 2017. And, by September 2017, the first version of the standard Data Models would be available, thanks to the previous work in projects like CitySDK, or the joining effort of FIWARE and a group of OASC cities in collaboration with GSMA, regarding the definition of harmonized Data Models. This partnership has produced a first batch of Data Models that are fully compatible with NGSI.

Participation in the cross-sector group is open to all ETSI members as well as organizations who are not members, subject to signing ISG Agreements. For information on how to participate please contact ISGsupport@etsi.org
The full list of members and participants in ISG CIM is available at: https://portal.etsi.org/TBSiteMap/CIM/CIMmembershiplist.aspx

imgpsh_fullsize

Assessing FIWARE GEs Quality

 APIs, Developers, Experimentation, GEs, NGSI  Comments Off on Assessing FIWARE GEs Quality
Sep 202016
 
Blue technology background with a bright piece.

FIWARE is rapidly moving from experimental to production environments in which the platform must scale in reliable and real workload conditions. This fact implies that all FIWARE GEris must work at an adequate quality, reliability and at performance level appropriate for these conditions. A dedicated activity has been launched in the framework of the initiative to analyze and assess the level of quality of each GE, providing diverse kind of reports and an assessment dashboard.

The quality is evaluated from different points of view:

  • Curation of GEs documentation (documentation testing), both inspecting the code and the accompanying documentation (installation manuals, user guidelines, and similar). The goal of this assessment is to support FIWARE users with high-quality support for installation, configuration and operation of FIWARE technology, thereby improving the FIWARE user experience in general.
  • Verification of the GE specification (functional testing), developing the appropriate test cases to assess if the GEs implementation corresponds to what is defined in the specification.
  • Assessment of performance, stability and scalability of GEs in operational environments, like under excessive workload (stress testing). Test scenarios are defined and executed such that limits of a GE under test are identified, and can be compared with reference levels. The goal of this assessment is to favor the applicability of FIWARE in purely commercial scenarios.

overallfunctionalThe testing of the documentation and verification has been done for all GE not deprecated in FIWARE Catalogue (28 in total). Three phases are required to complete the QA functional test process. The first phase verifies for each GE the completeness of documentation, the consistency of artefacts and the soundness of information.  The usability of documentation, by example, in case of installation manual is checked installing step by step the GE. In the second phase specific method calls verify the single APIs and the response correctness of each GEs. The last phase consists of functional verifications based on reference architectures integrating some GEs. As result a live dashboard collects and maintains the assessment information and GE owners are punctually requested to correct the encountered deficiencies. The 90% of the high priority GEs has passed successfully the documentation and verification tests. The medium and low priority GEs are above 70% of success but they are working on solving the issues

post-ges-2On the other hand, the stress testing has been performed only for those GEs most critical in terms of performance in the overall architecture. An iterative process and operative methodology have been put in place, obtaining after each iteration, a complete report with the measures obtained after stress test and analysis of the data. The reports are sent to the GE owners for considering improvements about performance and stability for next release. Three iterations will be achieved before end of September this year: one took place in February testing 9 GEs (Orion, Proton, Aeron, IDAS, Kurento, Wilma, KeyRock, Cepheus, Bosun); the second one in May testing new versions of these GEs; and final one due by September testing again a new updated version of these GEs plus two more identified (AuthZForce and Cygnus) and more frequent combination of GEs.

Once the first iteration of stress testing was conducted, a quality assurance expert was consulted for carrying out an independent assessment of the followed process and executed tests to produce an assessment of the achieved work. The main conclusions of his assessment were:

  • Important performance borders were identified
  • Robustness of use within bounds was shown
  • Documentation needs to be improved

According to this assessment, FIWARE GEs are fit for being released in a commercial operational environment with some adjustments. A new external independent assessment is currently being requested after second iteration.

http://i2.wp.com/sigspl.org/wp-content/uploads/2015/11/spl_cert.pngpost-ges-3As part of the overall testing process and based on the obtained results in the three aspects (documentation, verification and stress) above mentioned, an overall label of quality is granted to each GE. This global label represents the degree of quality of the GE by adopting the energy labelling system[1] used by EU for devices. Specific labels for each analyzed category (usability, reliability, efficiency, scalability, performance and stability) are also granted. Thus, in the Catalogue each GE will be labelled with a global label expanded by clicking of detailed labels map.

Now, after two phases in the process some overall conclusions can be stated. There exists a significant heterogeneity in the GEs quality, having more mature GEs and ready for market than others. There is still room for improvement in documentation and support for most of the GEs, which is currently in progress thanks to this activity. It can be also stated significant improvements in performance from first iteration to the second one, due to the following of recommendations in first iteration testing report by the GE responsible, which is also a demonstration of the value this activity can bring to FIWARE.

In near future, the main focus will be to enlarge number and type of tests and to automate the tests as much as possible, but in the meantime a set of guidelines have been created in order to be able to replicate all the conducted tests by anyone. All the tests and code are already public in FIWARE software repository and all the reports available through the FIWARE wiki.

For further information:

  • GitHub repository containing all docs (guidelines) and scripts (to run the tests) about non functional testing task (stress tests)
     
  • All the reports, up to date, in Docman, under Quality Assurance folder.
     
  • The FIWARE Quality Assurance chapter in our wiki.

[1] Figure under Common Creatives Share-Alike license by sigspl.org