fixo3 d2.10v1.0 finaldata products in a fairly automated way, i.e. without the often error-prone...

FixO3

FixedpointOpenOceanObservatoriesNetwork

GrantAgreementNumber:312463

The work described in this report has received funding from the European Union Seventh framework Programme (FP7/2007-2013).

WorkPackage2TechnologicalHarmonisation

Deliverable2.10Technicalguidelinesofstandardsofacceptabilityforcommonsensor

interoperabilityprotocols

Leadbeneficiary:PLATAFORMAOCEÁNICADECANARIAS(PLOCAN)-CONSORCIOPARAELDISEÑO,CONSTRUCCIÓN,EQUIPAMIENTOYEXPLOTACIÓNDELAPLATAFORMAOCEÁNICADECANARIAS

Leadauthor:EricDelory([email protected])

Contributors:SimonJirka(52°North),JanSchulte(52°North),ChristianAutermann(52°North),ChristianDanowski(52°North),JoaquíndelRio(UPC),Jean-FrançoisRolin(Ifremer),AndreeBehnken(Marum),GeorgePetihakis(HCMR),JohannesKarstensen(GEOMAR),NickO’Neill(SLR),ChristophWaldmann(MARUM),RobertHüber(MARUM),MarimarVillagarcia(PLOCAN),AndrésCianca(PLOCAN)

WorkPackageleader:VanessaCardin(OGS,[email protected])

Duedate:ProjectMonth40(12-2016)

Disseminationlevel:PU

FixO3Deliverable2.10-TechnicalGuidelinesofstandardsofacceptabilityforcommonsensorinteroperabilityprotocols

2


3

ContentsList of figures...................................................................................................................................5

EXECUTIVE SUMMARY...................................................................................................................7

1. INTRODUCTION.........................................................................................................................9

2.1. Background and objectives...............................................................................................9

2.2. Organisation of this report.................................................................................................9

2. METHODOLOGY........................................................................................................................9

3.1. Task participants and role..................................................................................................9

3.2. Standardisation landscape..............................................................................................10

3.3. European and Global Context.........................................................................................12

3.4. Research Projects.............................................................................................................13

3.5. Further Activities................................................................................................................17

3.6. Standards Baseline...........................................................................................................18

2.6.1. Introduction: OGC Sensor Web Enablement Overview......................................18

2.6.2. Sensor Web Encodings and Data Models.............................................................19

2.6.3. Sensor Web Interfaces.............................................................................................20

3.7. ESONET Yellow pages....................................................................................................26

3.8. SWE and Best Practices..................................................................................................26

3. RESULTS AND DISCUSSION...............................................................................................27

3.1. SensorML Editor (SMLE) source code..........................................................................27

3.2. SensorML Editor (SMLE) Manual...................................................................................27

3.3. Basic Visual Interface of SMLE.......................................................................................28

3.4. Modifiable Items and Restrictions...................................................................................29

3.5. Create SensorML Document from Template................................................................30

Find and Select Template........................................................................................................30

Instantiate and Edit new SensorML Document based on selected Template..................30

Preset Structure and Values of the Template.......................................................................41

3.6. Publish and persist new SensorML Document.............................................................45

3.7. Error Handling....................................................................................................................48

3.8. Create new SensorML Document..................................................................................49

3.9. View existing SensorML Descriptions............................................................................50

3.10. Edit your own SensorML Descriptions.......................................................................52

Role of the unique Identifier.....................................................................................................52

3.11. Restriction to only edit your own Content..................................................................53


4

3.12. Delete your own SensorML Descriptions..................................................................53

3.13. Restriction to only delete your own Content..............................................................55

4. CONCLUSIONS AND OUTLOOK..........................................................................................55

5. REFERENCES..........................................................................................................................55

6. ACRONYMS..............................................................................................................................57


5

Listoffigures

Figure1SMLEScreenshot-Sensortemplatesearchpage....................................................................8

Figure2OverviewoftheOGCSWEArchitecture[FixO3HandbookofBestPractices].......................19

Figure3WorkflowforInteractingwithSOSServers...........................................................................21

Figure4IEEE1451SystemArchitecture...............................................................................................23

Figure5HostissuesOGCPUCKcommandstoretrievedatasheetandpayload.................................25

Figure6Basedoninforetrievedinthefirststep,hostusesinstrument’s“native”protocoltoconfigureandacquiredata..........................................................................................................25

Figure7ScreenshotoftheO3YPwebinterface,anupgradeoftheESONETYellowPages(EYP)......26

Figure8SMLEEditorsourcecode.......................................................................................................27

Figure9SMLEhomepage...................................................................................................................28

Figure10GithubCredentials...............................................................................................................29

Figure11SMLEtemplateselection.....................................................................................................30

Figure12SMLEinstantiation...............................................................................................................31

Figure13SMLEinstantiation-step1..................................................................................................32









Figure22SMLEinstantiation-step10................................................................................................41

Figure23Replacing/Overridingvalues1.............................................................................................42



6



Figure27Publishnewsensorinstance1.............................................................................................46




Figure31Errorhandling1...................................................................................................................48

Figure32Errorhandling2...................................................................................................................49

Figure33Createnewsensor1............................................................................................................49

Figure34Createnewsensor2............................................................................................................50

Figure35Viewingsensorinstance1...................................................................................................50



Figure38Editsensorinstance.............................................................................................................53

Figure39Deletesensorinstance1......................................................................................................54




7

EXECUTIVESUMMARYTechnologicaldiversityinthedevelopmentandoperationofin-situearthobservationsystemscallsforgreaterinteroperabilityofsystemsacrossdomainsandnetworks.Thisisevenmoresoinoceanobservationwhere there isanotoriousdegreeofheterogeneitybetweenobservingsystems, fromsensorstodatarepositoriesandservices.Thisdeliverableproposesawaytoovercomepartoftheproblembyaddressingtheinteroperabilityneed,rightatthesensorlevel,wherealargeamountofinformationrelatedtotheresultingobservationscanbetracedfromandthenbeembeddedinfinaldata products in a fairly automated way, i.e. without the often error-prone intervention ofoperators.Thisisparticularlyimportantwhendataaredeliveredreal-timeinaservice-orientedtypeofarchitecture.

First a rationale is developed for the use of SensorWeb services, based on theOGC SensorWebEnablement(SWE)suiteofstandards.Thesestandardsrespondtoaseriesofrequirementsthatfulfilpart of the objectives of the FixO3 project in terms of technical harmonisation of the EuropeannetworkoffixedOpen-OceanObservatories.Whilealternativesarealsobrieflydescribed,theSWEframeworkofferssolutionstoincreasethetraceability,qualityandreliabilityofsensormetadataanddata products, increase the performance and ease ofmaintenance of observing systems, simplifyand improveofusability, implying reductions in costofoperations, and increase thecompatibilityandinteroperabilityofdataandsensorservices.

WhiletheSWEframeworkshowspotentialindeliveringanewmethodforharmonization,thereisaneedtodeveloptoolsfortheirimplementation.Thisstartswiththeproperregistrationofsensors,inSensorMLformat,whichisthebasisforallotherservicesintheframework.

Auser-friendlyeditor(SMLE,seethepicturebelow)wasthereforedeveloped,whichhasconsistedinthecoreoftheworkthat isreportedherein.Thedocument includesanexhaustiveusermanual inordertofosteritsuseacrossthecommunity.

SMLEisopensourceandisavailableatthefollowingURL:

https://github.com/52North/smle

ItslatestdeploymentfordemonstrationisavailableatthefollowingURL:

http://pilot.52north.org:3000/#/templates


8

NextstepsincludethedevelopmentofalinkwiththeFixO3portal’sobservatoriessectiontoavoidmultiplicityofaccesscredentials(unifyingbothresources)andtostarttestingtheinterfacewiththeusercommunityinFixO3.Fromthereceivedfeedbacksuggestedchangeswillbeimplemented(version1.0).

Figure1SMLEScreenshot-Sensortemplatesearchpage


9

1. INTRODUCTION

2.1. BackgroundandobjectivesThereportedactivitybuildsupontheresultsobtainedondefining,designingandimplementingtheSensor Registry using the OGC SensorML standard in ESONET, with the objective to develop andpromotethesensorregistryacrosstheprojectinfrastructures.OneofESONET’sgoalswastocreatea suite of interoperability tools for a Sensor Registry interface. The Sensor Registry is based onstandardhardwareandweb-basedinterfacesfortheregistrationandstandardizationofobservatorysensors, facilitating the transcription ofmain sensor specifications and operational characteristicsintoamachine-discoverableandreadablestandarddigitalformat.Asplanned,thisinterfaceenablesthe discovery and broadcast of sensor data, as well as the manufacturing of a smart interfacecommunications prototype that allows direct communication between a sensor and its databaseregistry.Thisstandardizationprocessgeneratesthefollowingbenefits:

•Increaseinthetraceability,qualityandreliabilityofsensormetadataanddataproducts

•Increaseinperformanceandeaseofmaintenanceofobservingsystems

•Simplificationandimprovementofusability,implyingreductionsincostofoperations

•Increaseinthecompatibilityandinteroperabilityofdataandsensorservices

Thistaskislinkedtothe“OpenOceanObservatories”YellowPages(O3YP)incorporatingnewsensortemplatesandwhichcanbeautomaticallyeditedasSensorMLtemplatesbyusersfromthesensorregistration interface. A user-friendly manual for scientific users has been created and its use isbeingencouragedwithintheFixo3community.

2.2. OrganisationofthisreportThe report includes the description of the standardisation landscape with respect to sensorinteroperabilityinin-situoceanobservation.Arationaleisderivedthatpromotestheuseofasetofstandardsandleadstothedevelopmentofauser-friendlyinterfacetoenabletheimplementation.The resultsarepresentedbymeansofadescriptionof thedevelopmentsperformed inFixO3 task2.6.Thechosenformatforthedescriptionwasdecidedtobeausermanual,sothatthecommunityin FixO3 andbeyond canhave clear instructions for properuseof theuser interface,while at thesametime“see”theactualresult.

2. METHODOLOGY

3.1. TaskparticipantsandroleInordertoestablishacollaborativeframeworkfortheexecutionoftask2.6,specificpartnerrolesandestimatedeffortsfortheentiredurationoftheprojecthavebeenassigned.Specifically:

1. PLOCAN:Coordinatetask,provideguidancefromESONETsensorregistryworkandnewOCEANSprojectsinordertosetrequirements,provideserverspaceforservicedeployment


10

2. 52°North:UpgradesensorregistrycodeforSML2.0compliance,usermanagementandreadingyellowpagesformatsensorinstancesprovidedbytask2.5,deployupgradedservice.

3. UPC:support52°Northforsmartsensorregistrationandcoding.4. SLR:provideyellowpagessensorformatdocumentation,supportto52°Northforreading

fromsensorregistry(connectionwithtask2.5)5. Ifremer:Informonthedevelopmentofnewsensortypescreatedintask2.5.Provide

guidancefromotherprojects.6. GEOMAR:Provideguidanceondefinitionandfeedbackasbetatester7. OGS:OverseedevelopmentsasWP2lead,ensurethatT2.6andT2.5plansarealigned(WP

lead).8. MARUM:ProvideguidanceandsupporttoalignwithWP4work.Provideserverspaceas

back-upormirror.9. HCMR:CreateaBest-Practiceprotocolforsensorregistrationtargetedtousers.Linkwith

WP3.TheSensorWebarchitectureisnowpromotedinthe[FixO3HandbookofBestPractices]

3.2. StandardisationlandscapeOcean observations data sets are often collected on a project-basis and, when available, are notalways interoperable, and therefore difficult to exploit in broader contexts. Fragmentation,availability gaps, duplication, identification problems, access and usability are common issues. Inresponse,thespatialdatainfrastructure(SDI)approachisenvisionedforthedevelopmentofmarinesensornetworkstocreateenvironmentsthatenableuserstoaccessandretrievespatialdatasetsinaneasyandintuitiveway.ImplementingmarinesensornetworksusinganSDIapproachwilleasetheuseandsharingofspatialinformationandservicestosupportspatial-temporaldecisionmakingformultiplepurposes [SDI].Otherbenefits are the improvedaccessibility todata and interoperabilitybetween data sets. However, interoperability can only be achieved through extensive use ofinternationalstandards.Theyspecifyregulationsfordataaccess,content,andexchange.Themostimportant internationalstandardspromoted inthe lastyears forthedevelopmentofSDIsare: theset of standards developed by Open Geospatial Consortium (OGC), the geographic informationstandardsdevelopedbyInternationalOrganizationforStandardization(ISO)andtheIEEE1451setofsmart transducer interface standards developed by the Institute of Electrical and ElectronicsEngineers (IEEE) Instrumentation and Measurement Society’s Sensor Technology TechnicalCommittee.

OGC(e.g.SensorWebEnablementDWG,SWE-IoTSWG,MetOceansDWG)

The Open Geospatial Consortium (OGC) is a non-profit de facto international standards body forgeographic information. The new standards developed byOGC represent a conceptualmodel forObservations and Measurements (O&M) [OGC-Architecture]. This standard describes how anobservation isanactionwhose result isanestimateof thevalueof somepropertyofa featureofinterest, obtainedusinga specifiedprocedure. TheO&Mconceptualmodelhasbeen substantiallydevelopedsince2002throughsuchinitiatives(OWS-1.2andOWS-3).Itwasfinallyapprovedin2008as version1.0 forpublicationby theOGC, andwasprogressedas version2.0 to the ISO standard19156. The abstract O&Mmodelmay be applied across the spectrum of sensor applications anddeployments,andprovidesaframeworkforbuildingexchangestandardsandserviceinterfacesforaccessing sensor data and contextual information. For example, the Sensor Observation Service(SOS) provides aWeb service interface for retrieving filtered observations or related information(feature-of-interest,sensorparameters,observationresults).Individualsensorobservationsmaybe


11

aggregatedwithinone service into combined 'observationofferings' andmultiple servicesmaybefederatedintosingleaccesspoints.TheSensorModelLanguage(SensorML)isanXMLlanguagefordescribing observation procedures and sensor types. Other related standards include the SensorPlanningService (SPS) for taskingandschedulingobservation requestswith sensor systems (egbysatellite remote-sensing instruments), and eventing components for setting up notificationsubscriptionsforspecificsensorevents.

Within Europe, theDirective (2007/2/EC) established the 'Infrastructure for Spatial Information inEurope' (INSPIRE) to integrate environmental data across all member states. The 'Copernicus'partnershipbetweentheEuropeanCommissionandtheEuropeanSpaceAgencywillestablishcoreoperational services (e.g. ocean forecasting, land cover monitoring, emergency response) for theglobalenvironmentandcivilsecurity.Thesethreeglobal-scaleinitiativesallpromotetheuseofOGCstandard informationmodels and network services for integrating sensor data - both in situ andremotelysensed(spaceborneandairborne).

ISO

TheresponsiblefortheISOgeographicinformationseriesofstandardsistheISO/TC211Geographicinformation/Geomatics [ISO]. ISO/TC 211 establish a structured set of standards for informationconcerningobjectsorphenomenathataredirectlyorindirectlyassociatedwithalocationrelativetothe Earth. These standards are collectively referred to as the ISO 19100-series. These standardsspecify for the fieldof geographic informationdifferentmethods, toolsand services formanaging(including definition and description), acquiring, processing, analysing, accessing, presenting andtransferringsuchdataindigital/electronicformbetweendifferentusers,systemsandlocations.

TheoverallobjectivesofISO/TC211are:

• toincreasetheunderstandingandusageofgeographicinformation;• toincreasetheavailability,access,integration,andsharingofgeographicinformation;• topromotetheefficient,effective,andeconomicuseofdigitalgeographicinformationand

associatedhardwareandsoftwaresystems;• tocontributetoaunifiedapproachtoaddressglobalecologicalandhumanitarianproblems.

IEEE

The IEEE 1451 Smart Sensor Interface Standard provides a common communications architecturewith sensors over different communicationprotocols at thephysical level.Different protocols areaddressedbydifferentbranchesofthestandard,forexample,1451.2forRS232,I2C,andSPI;1451.4foranalog sensors,1451.6 for controllerareanetwork (CAN), and soon [IEEE1451]. This standardhasnotyetbeenwidelyused,especiallyinmarinesensors,anditsadoptionishamperedbyalackofsoftwaretoolsfor implementation.However, ithassomecapabilitiesthatmaybeuseful inmarinenetworks. Though there have been many incremental steps toward instrument integration as itapplies tomarine sensornetworks, therehasnotbeena standards-basedarchitecture thatofferspracticalend-to-endplug&workcapability.Hence,thearchitectureweproposeprovidesapracticalend-to-endsolutionusingOGC-SWEstandardstoimplementdistributedandgeospatiallyreferencedsensornetworks.


12

3.3. EuropeanandGlobalContextINSPIRE

The Infrastructure for Spatial Information in the European Community (INSPIRE) directive is animportant European legislative foundation. It defines the foundations of a spatial informationinfrastructureonaEuropeanlevelinordertostrengthenandfacilitatetheexchangeofgeographicinformation. The INSPIRE Directive entered into force on 15th May 2007 and is currently in theprocessofimplementation.

The INSPIRE framework comprises several elements regulating the exchange of geographicalinformation.Ontheonehand itdefinesobligationsforpublicadministrationwhichdatahastobemadeaccessibleinaINSPIREcompliantmanner.Ontheotherhanditspecifieshowthisdatashallbeprovided. These specifications include both, the specification of data/metadatamodels aswell asservicetypesfordiscoveringandaccessingthesedatasets.

Currently a process is ongoing to enhance the INSPIRE technical guidance to better support theprovision of observation data. In the upcoming years several data topics defined in the INSPIRETechnicalGuidelinesAnnexIIandIIIwillneedtobedeliveredbyresponsibleagencies inaINSPIREcompliantmanner.Thiswillalsocompriseoceanographicgeographicalfeaturesandsearegions. InthecurrentprocessaproposalisindevelopmentdescribinghowtheOGCSOScanbeincorporatedintotheINSPIREframeworkasaso-calledDownloadService1.Thus,toensureINSPIREcomplianceoftheSensorWebarchitecture inFixO3, it is importanttoconsidertheseactivitieswhenselectinganinterfacefortheprovisionofobservationdata.

Furthermore, INSPIRE relies on the ISO/OGC O&M standard for the modelling and encoding ofobservationdata.

GEOSS

TheGlobalEarthObservingSystemofSystems(GEOSS)isaglobalinitiativewiththeparticipationofmore than 70 countries. The aim of GEOSS is to facilitate and strengthen the exchange of earthobservationdatatosupporttheworkontopicssuchasthemanagementofdisasters,humanhealth,water supply, climate change, biodiversity, and the protection of ecosystems (including marineecosystems).

For several years, there have been ongoing activities to agree on standards for the exchange ofrelevantdatasets.This includesforexamplealsoseveralworkshopsanddiscussions inthefieldofSensorWeb.Within GEOSS, a framework such as the OGC SWE framework will be an importantmeansfortheprovisionofin-situmeasurementdata.

Several test beds (the so called GEOSS Architecture Implementation Pilots (AIP)) have beenconductedtoevaluateanddemonstratepotential technologies to implementGEOSS.Duringthesetestbeds theuseofOGCSWEstandardshasbeen shown. Furthermore,documentationhasbeendevelopedtoofferdataprovidersguidancehowthesestandardscouldbeappliedinthecontextofGEOSS.

1https://ies-svn.jrc.ec.europa.eu/projects/download-services-tg/wiki/SOS_sub-group


13

Finally, European projects such as EO2HEAVEN and GEOWOW have addressed the topic ofobservationdatainGEOSS.Alsohere,SWE-basedsoftwarecomponents(e.g.the52°NorthSOS)andconceptsweredeveloped.

Thus, it can be concluded, that the implementation of SWE standards in FixO3 will ensure analignmentwithGEOSSactivities.

Copernicus

Copernicus, formerly known as GMES (Global Monitoring for Environment and Security), is aEuropean Programme that aims at establishing European capacity for Earth Observation. Itaddressesboth,in-situaswellasremotesensingobservationdata.AtthesametimeitisaEuropeancontributiontoGEOSS.

Copernicus covers the following thematic domains: land, marine, atmosphere, climate change,emergencymanagementandsecurity.Forthesetopics,Copernicushastheaimtodeliverrelevantobservationdataaswellasservicesbasedonthesedatasetstopolicyanddecisionmakers.Thus,theCopernicusframeworkisalsoofinteresttoFixO3activities.

In the context of Copernicus, theMyOcean activities are of special relevance. This project (whichconsists of two subsequent projects) aims at an integrated pan-European capability for oceanmonitoringandforecasting.

Thus, forFixO3 it is recommendedto followthe furtherevolutionofCopernicusandtheMyOceanactivities.

3.4. ResearchProjects

I3EUROFLEETS2

EUROFLEETS22(NewoperationalstepstowardsanallianceofEuropeanresearchfleets)followstheEUROFLEETS1project.ThemaingoalofthesetwoprojectsisacollaborativecoordinationeffortofEuropeanResearchFleetowners.

BeforetheEUROFLEETSproject,theEuropeanmarineresearchhadabroaderfragmentationandalackofcohesionandstrategicvision.EUROFLEETS1startedinSeptember2009withtheaimtobringtheexistingEuropeanFleetownerstogetherandstrengthentheircoordination.Themainobjectivesofthisprojectare:

• agreementonacommonstrategicvisionfortheEuropeanresearchfleets• development of a way that research vessels are operated and their interoperability

capacities• promotionofinteroperableandstandardizedresearchtoolsforthevesselsandunderwater

vehicles

2http://www.eurofleets.eu


14

EUROFLEETS2buildsupontheachievementsoftheprecedingproject.ItstartedinMarch2013andhas duration of 4 years. This project shall increase the cooperation and coordination structure,facilitatetheaccesstohighlyperformingresearchvesselstoalargercommunityofresearchers,andcreatemorelinkswithindustry.Themainobjectivesinthisprojectphaseare:

• increasetheparticipationofresearchvesselsboththeglobal/oceanandtheregional• integrateacommonpolarinthestrategicvisionofEUROFLEETS1• promotetheexchangeofmobileequipmentonboardofEuropeanresearchvessels• largerandambitiousresearchmissionsbycoordinatemulti-vesselsexperiments• operationalexperimentalteststodemonstratetheinteroperabilityoftheEuropeanfleets

WithintheEUROFLEETSprojectstheOGCSWEtechnology(forexample,SensorMLisusedtocreateShipSummaryReports)isconsideredfordataexchangepurposes.ThisisinlinewiththeaimsoftheSensorWebapproach.

ESONET

ESONET3standsforEuropeanSeasObservatoryNETworkandisascientificandtechnicalnetworkfordeepseaobservations.Itwasfundedfor4yearsbytheEuropeanCommissioninthe6thFrameworkProgramme(FP6).Itpromotedtheimplementationandthemanagementofanetworkforlong-termmultidisciplinaryoceanobservatoriesindeepwatersaroundEurope.

AnESONETobservatoryisdefinedasadeepseastationwithmarinesensorsthatarelinkedtotheshore by acoustic or cable connection and provide the measured data in near-real time. Theseoceanographic and climatological data sets are offered in a high frequency. The deep seaobservatories are complementary options to satellite images, research vessels or moorings. Thisapproachhasthefollowingadvantagesregardingthepreviouslymentionedoptions:

• reallylong-termobservations(foratleast10years)• monitoringthroughoutthewatercolumn• thepowersupplyforthemeasurementsismanagedwithcablesfromtheshore

InESONETWP2(Standardsand Interoperability), ledbyChristophWaldmann(MARUM),aspecificactivityhasconsistedinthedevelopmentofafirstversionofasensorregistrationinterface,basedontheSensorML1.0.1standard.ThetoolwasdevelopedbydBscaleTechnologieswithcontributionsfromMarum,Ifremerand52north.52Northtookonthedevelopmentstoredesignanewinterface,meanttobeuser-friendlyandmostnotablyopen-source,basedonthelatestversionofthestandard(SensorML2.0)–thiswork.

SEADATANET

The SeaDataNet4 (pan-European infrastructure for ocean and marine data management) projectprovides an efficient distributed Marine Data Management Infrastructure. This infrastructuremanages,indexes,andprovidesaccesstolargeanddiversemarineandoceandatasetsderivedfromin-situandremote,seaandoceanobservations.

3http://www.esonet-noe.org4http://www.seadatanet.org


15

TheEuropeanmarineobservingsystemishighlyfragmentedandthedataismeasuredusingvarioussensorsonboardofresearchvessels,submarines,airplanesandsatellites.Themeasuredphysical,geological, biological or chemical parameters are neither easily accessible nor standardized.SeaDataNet is based on an interconnected network of data centres and provides the data in auniquevirtualmanagementsystem.Thus,theobjectiveintheSeaDataNetprojectistoprovidethecollecteddata inonline integrateddatabaseswithastandardizedquality.Theaccesstothe in-situmeasurementsandmetadataisofferedbyauniqueportalandwasimplementedinthefirstphaseofthisproject.

TheimplementationofaCommonDataIndex(CDI)metadataservice(Sea-Searchproject)leadstoalinkingbetweendiscoveryanddeliveryofdatasets.ACDIinterfaceprovidesafiltermechanism(e.g.availability,geographical)tospecialisethesearchresults.Todefineanextendedmetadataformattosupport the CDI SensorML profiles are used to describe instruments and sensors. Also the O&Mstandard comes to the front to adapt themarine observation data. These efforts should also beconsideredfortheFixO3activities.

The objective in a second phase of SeaDataNet is an upgrade of the current SeaDataNetinfrastructure to an operational robust and state-of-the-art pan-European infrastructure. ThissecondphasestartedinOctober2011foradurationof4years.Thesecondphaseshouldbefulfilledby:

• setting,adoptingandpromotingcommondatamanagementstandards• realizing technical and semantic interoperability with other relevant data management

systemsandinitiativesonbehalfofscience,environmentalmanagement,policymaking,andeconomy

GROOM

TheGROOM5(GlidersforResearch,OceanObservation&Management)projectaddressesastudytoevaluate the requirements to setupa sustainableEuropeanglider infrastructure. Thisprojecthasstarted inOctober 2011with a duration of 3 years. The development of the glider infrastructureshouldcreatecontinuousobservationsofindividualoperatingglideraswellasfleetsofgliders.Thegoal is to coordinate the operations with benefits for both fundamental marine research andoperational oceanography. The study should reveal that a close coordination of a distributedarchitecture of “gliderports” around the European seas and overseas is required. In combinationwithexistingobservingsystemsleadsthistoabettervalueofmoney.

TheGROOMprogramfocusesonthefollowingpoints:

• integrationofglidersintotheexistingglobalandregional/coastaloceanobservingsystem• raisingissuesbythisinfrastructureregardingtheLawoftheSeaandmaritimetraffic• strategiclocationnetworkwithcoordinationofexistingobservationactivities• use existing data management infrastructure framework to collect and publish valid and

qualitycontrolleddatasets• support anopenaccessoption to thegliderdata toenhance theeducational viewon the

oceansandtheimportancefortheclimateandresources

5http://www.groom-fp7.eu


16

NeXOS6

Toachieveamaximum levelof interoperability, it is important toestablishapplicationprofiles fordata exchange standards.NeXOSdevelops suchprofiles for the ocean community sincewithin itsconsortiumthedomainsofmarineknowledgeandtechnicalexpertisemerge.Theseprofileswillbebasedonexistingwork,suchashasbeenstartedintheESONETproject.

They will be designed as best practices for marine sensor network providers and submitted byNeXOS to the OGC standardization process. In addition to the development of profiles, NeXOScontributes with practical experience and evaluation mechanisms to the next evolution of SWEspecifications,whichwill shape SWE3.0. Inparticular,NeXOSaddresses specifications to improvethe processes of marine data acquisition. Utilization of the standardized SWE specifications anddevelopment of the required profiles, will allow seamless integration with existing internationalinitiativessuchasGEOSSandCopernicus.

Several partners of the FixO3 consortium are also involved within the NeXOS project. Thisinvolvement guarantees that thework reported hereafter alignswith the development of sensorwebservicesinNeXOS.

X-Domes–Earthcube

Shortfor“Cross-DomainObservationalMetadataforEnvironmentalSensing”,X-Domes7objectiveisthe development of a standards-based description of environmental sensor metadata, includingprovenance.LeveragingexistingrelationshipswithlargeNationalScienceFoundation(NSF)-fundeddata management programs, EarthCube building blocks and working groups, and environmentalsensormanufacturersandconsortia,X-Domeswillestablishacommunityofsensormanufacturersandotherstakeholderstoprovideaunifyingapproachtodescribingsensorsandobservationsacrossgeo-science domains. Built on an existing sensor metadata model that references registered,standards-based vocabularies, the X-DOMES pilot project will provide a suite of tools, built uponcommunity-adopted standards of the Open Geospatial Consortium (OGC) and World Wide WebConsortium (W3C) to demonstrate and facilitate the generation ofmetadata documents that arediscoverableandaccessibleon-lineand/ordirectly fromonboard sensordescriptions. Theprojectwillalsodemonstratemechanismstoassociatethedatawiththemetadatathroughstandards-basedwebservices.Withvendor-readytools implementedthroughoutabroad-basedcommunity,theX-DOMES Network will lay the foundation for the development of and adoption of interoperableaccess tomuchneededcontent-richsensormetadata.ConsideredasaparallelUS initiative to thework described in this report, X-Domes further demonstrates the growing interest in thedevelopmentoftoolsfortheimplementationoftheOGCSWEstandards,andheremorespecificallytheSensorMLstandardspecificationforencodingsensormetadata.

6http:/www.nexosproject.eu - NeXOS has received funding from the European Union’s Seventh Programme for research, technological development and demonstration under grant agreement No 6141027https://www.earthcube.org/group/x-domes


17

3.5. FurtherActivities

ResearchInfrastructures(e.g.ICOS,EMSO)

The IntegratedCarbonObservationSystem8 (ICOS)project is in itspreparatoryphase (2008-2013).Carbon fluxes are tracked in Europe and bordering regions with the help of an atmospheric,ecosystemandmarinenetwork.This long-termobservationhelps tounderstand thepresentstateandpredictfuturebehaviourofclimate,theglobalcarboncycleandgreenhousegasesemissions.

EMSO9 (European Multidisciplinary Seafloor and water column Observatory) is a Europeaninfrastructure. This network of specific sites off European coastline includes deep sea cabled andopen-ocean observatories that monitor environmental processes, real-time and delayed-mode. Aunique organisation at European levelmanaged this long-termobservations related to ecosystemand global changes. EMSO decided to implement core standards of the OGC, such as CatalogueService for Web (CS-W). Besides this, efforts to use the SWE standards SOS and O&M wereundertaken.ThisshowsagaintherelevanceoftheSWEtechnologyforFixO3,forwhichanumberofobservatorieshavealreadyjoinedtheEMSO-ERICentity.

OtherInitiatives(e.g.OCEANSITES,ODIP,IOOS)

OceanSITES10 is a systemofworldwide deepwater stations. It relies on long-termmeasurementsandmonitorsthefulldepthoftheoceandownto5000metersincludingsea-airinteractions.Since1999, the observations are collected by moorings and research vessels and satellite telemetryenables near real-time access to the produced data. The main observation parameters aremeteorology, physical oceanography, water transportation, biochemistry carbon cycle relevantparameters.Besidessatelliteimageryandotherin-situobservationsOceanSITESisaninherentpartof the Global Ocean Observing System (GOOS). The focus in this project is the gathering ofmeasurementdata,sothegathereddataisprovidedinaselfdevelopedNetCDF(NetworkCommonDataForm)dataset format.Besides this, thesensormetadatadescriptionsarebasedon theOGCSensorMLstandard.

AsoceanandmarinedataarerecognisedasvaluableresourceswhichhaveahighcostofacquisitionthemaingoalofOceanDataInteroperabilityPlatform11(ODIP)istoprovideeasyaccessofoceanicdata across scientific domains and international boundaries. Themajor involvedorganisations aretheEU,USandAustraliaandtheprojectisfundedwithinEUFP7foradurationof36monthsfromOctober2012toSeptember2015. Internationalworkshopsundertheorganisationofthisplatformraise the development to reach the goal of interoperable used datasets. Another objective is toharmonise the diversion in the regional systems. A prototypical implementation is planned. ThisprototypeshouldadoptthemainstandardsoftheOGCSWEworkinggroup,whicharetheencodingsto describe the provided data sets (SensorML and O&M) as well as the SOS protocol to provideaccess to modelled data sets. From FixO3 (and NeXOS, among others), 52°North supports theseactivitieswithitsSWEimplementations.

8http://www.icos-infrastructure.eu9http://www.esonet-emso.org10http://www.oceansites.org11http://www.odip.org


18

The Integrated Coastal and Ocean Observation System (ICOOS) Act of 2009 manifests thedevelopmentoftheU.S.IOOS12(IntegratedOceanObservingSystem).Thisprojectisfocusedonaneasierandbetteraccessofmeasureddataintheocean,thecoastalandtheGreatLakesregion.TheIOOS is composed in a national-regional partnership, whichworks on new tools and forecasts toimprove safety, enhance economy and protect the environment. With the information and datawhichiscollectedinretrospectivelyandnearreal-timetheobjectiveistoimprovethepredictionofcoastalevents,forexamplestorms,waveheightsandsealevelchanges.Fortheimplementationofthe self-defined goals of interoperable data access the IOOS uses the SensorObservation Servicestandardwithsmallmodificationsfortheirneeds.

Practicalapplications

Besidestheresearchprojectsmentionedintheprevioussections,theSensorWebtechnology,andespeciallytheOGCSWEframeworkhasalreadybeenappliedinvariousdomains.Thefollowinglistgivesashortoverviewofprojectexamples:

• German Federal Waterways and Shipping Administration: SOS servers and clients forproviding/visualisingabroadrangeofhydrologicalmeasurementdata

• EuropeanEnvironmentAgency(EEA):CollectionofairqualitydatafrommemberstatesandprovisionofthesecollecteddatasetsinastandardisedmannerviatheOGCSOS

• BritishAntarcticSurvey:ProvisionofmeteorologicalmeasurementdatafromAntarcticaviaaSOSserver

• TheU.S. IntegratedOceanObservingSystem(IOOS):OperatedbytheUSNationalOceanicandAtmosphericAdministration(NOAA);provisionofoceanographicmeasurementsviaSOSservers.

• IRCEL-CELINE (Belgian environment agency): Provision of air quality data through the SOSstandard

• BarcelonaPortAuthority:AccesstoshiptrackingdataviaaSOSserver

ThislistshallonlyprovideageneraloverviewofpossibleSWEapplication.Itillustrates,thatSWEisnotonly relevant foroceanographybut for abroad rangeofdomainsdealingwithenvironmentalobservations.Asaresult,theusageofSWEstandardswithinFixO3,withthesupportoftoolsetssuchastheonesdevelopedinprojectslikeNeXOS,willnotonlybeinlinewithoceanographicprojects.Inaddition it will also ensure the interoperable data exchange with other environmental researchfields.

3.6. StandardsBaseline

2.6.1. Introduction:OGCSensorWebEnablementOverviewTheOpenGeospatialConsortium(OGC)comprisesover400companies,governmentalagenciesanduniversitiesandactsasanon-profitorganisation.Themaingoalsarethedevelopmentofstandardsfordatamodelsandwebservicesinaspatiotemporalarea.

The SensorWeb Enablement (SWE) domainworking group is aworking group of the OGCwhichdevelopsstandardsforsensordataandmetadatainthegeospatialweb.Generallythestandardsinthe SWE framework can be divided in information and interface standards. The information

12http://www.ioos.noaa.gov


19

subgroupdefinesstandardsfordatamodelsandsensorwebencodingswhiletheinterfacesubgroupareresponsibleforthedifferentsensorwebserviceinterfacespecifications.

Figure2OverviewoftheOGCSWEArchitecture[FixO3HandbookofBestPractices]

Figure2showsanoverviewoftheOGCSWEarchitecture.Itcomprisesthefollowingcomponents:

• DataModelsandEncodings:o ISO/OGCObservationsandMeasurementsmodelsthegatheredmeasurementdatao OGC Sensor Model Language describes the sensors and processes which have

acquiredacertainobservationdataset(àprovisionofmetadata)• ServiceInterface:

o OGC Sensor Observation Service: interoperable access to measurement data andsensormetadata

o OGCSensorPlanningService:interfacetosendtasksandconfigurationstosensorso EventServices:subscriptiontodefinedeventsandalertingifthedefinedeventsare

detected

2.6.2. SensorWebEncodingsandDataModels

ISO/OGCObservationsandMeasurements(O&M)

TheO&M2.0standarddescribesamodelandanXMLSchematoencodedatagatheredbysensors(archived as well as real-time data). A basic observation designed with O&M is based on thefollowingparameters:

• theprocess(e.g.asensor) isconstitutedbytheprocedurewhichhasperformedaspecificobservation

• theobservedpropertyreferstotheparameterwhichisobserved(e.g.waterlevel)• thefeatureofintereststandsforthegeospatialobject(e.g.ariversection)intherealworld

forwhichthepropertyisobserved


20

• and theobservation's resultwhich is the valueof themeasurement (in this caseawaterlevelvalueincentimetres)

OGCSensorModelLanguage(SensorML)

Coretothiswork,theOGCSensorModelLanguage(SensorML)isdefinedtodescribethesensororprocessmetadata. Similarly to O&M the SensorML 2.0 standard describes the processes by datamodels andwith the help of an XML encoding. A process is either ameasurement procedure orprocessing of previously gathered data. A SensorML document may comprise for example thefollowingparameters:

• keywords:shorttermscharacterisingthesensor• identification:identifierstoensureauniquereferenceofthesensor• classification::classifiersfordiscovery• validTime:timerange,forwhichthesensordescriptionisvalid• inputs:inputsfortheprocess• outputs:resultingoutputstotheprocess• characteristics: additionalpropertiesof theprocess thatdonot furtherqualify theoutput

values(e.g.componentdimensions,batterylife)• capabilities: properties which clarify or qualify the measurement process (units for the

output,observedarea)• contact:institution,whichoperatesthedescribedsensorinstance

The characteristic parameter may also describe for example the temporal availability and thepositionofthedescribedprocessorsensor.

Theworkreported in the followingsectionsaddresses theneedtosimplify the implementationofthe standard in FixO3, via the development of a new sensor registration interface designed tointegrateseamlesslywiththeFixO3portalcredentialsandtheESONET-FixO3YellowPages(FixO3task

2.5), and the developments of SWE-based SDI. This interface development builds upon a priorprototypedevelopedintheESONETNetworkofExcellence(FP6).

2.6.3. SensorWebInterfacesOGCSensorObservationService

TheOGCSensorObservationService(SOS)isthebestknownWebserviceoftheSWEworkinggroupandismanifestedinSOS2.0standard.TheSOSdeliverspull-basedsensormetadataandassociateddata. This service works as middleware between clients and a measurement archive or sensornetwork. Through the SOS, clients can access the data of heterogeneous data sources via astandardizedinterface.RequestedmeasurementsareencodedinO&Mwhilesensorisrepresentedby SensorML documents. The operations in the SOS are divided in the core functionality andextensions.ThecoreoperationsoftheSOSinterfaceare:

• GetCapabilitiesdeliversthemetadatatotheserviceinstance• DescribeSensordescribesthemetadataforsensorsorprocesses• GetObservationdeliversthemeasurementdataThe transactional extension allows the insertion of new sensor metadata (RegisterSensoroperation)andmeasurements(InsertObservationoperation).


21

Figure3WorkflowforInteractingwithSOSServers

Figure 3 shows two sensors which communicate use the transactional operations to push theirmeasurement data into a SOS server. On the consumer side a client first requests themetadataabouttheservice(GetCapabilities)andthenoftheindividualsensors.ThroughtheGetObservationoperationtheclientfinallyobtainsthemeasurementsofthesensors.

OGCSensorPlanningService

TheOGCSensorPlanningService(SPS)offersandinterfacethroughwhichsensorscanbetaskedorparametersofsensorscanbemodified(ifsupportedevenatruntime).LiketheSOS,theSPSisalsoaWebserviceinterfacespecification.Itallowsclientstocontrolsensorswithpredefinedtasks.

AnSPSserverprovidesthefollowingoperationstoplanandcontrolsensortasks:

• GetFeasibilitycheckswhetherataskforaspecificsensorisfeasibleornot• withtheSubmitoperationataskissenttoasensor• byGetStatusasubmittedtaskcanbechecked• DescribeTaskingdeliversinformationhowtoformulatetaskingrequestsandhowthesyntax

lookslike• WithDescribeResultAccesstheconsumentgetstheinformationhowtoaccessthegathered

sensordata.

Eventing

Theeventingcomponents realizepush-based,asynchronousdeliveryof sensordata.Thiseventingmechanism is based on a publish/subscribe communication pattern, which is different from theconventional request/response communication as used in the SOS for example. A consumersubscribes for a notification and the service forwards the new incoming measured data to thesubscribedconsumerinnearreal-time.Thisalsosavesperiodicalrequest/responsecommunication.

Recently, a new OGC standard for this functionality was released: The OGC Publish/SubscribeInterface Standard13. However, as this standard is rather new, the number of implementations is

13http://www.opengeospatial.org/standards/pubsub


22

currently still limited. An on-going effort is the development of a Publish/Subscribe Sensor Webserviceby52°North.

OGCSensorThingsAPI

To cover the specific conditions of the Internet of Things (i.e. low bandwidth, limited processingpower) the OGC SWE IoT Standards Working Group was founded. The idea behind this workinggroup is to develop specialised variants of the OGC SWE standards that are optimised for theInternetofThings.Maincharacteristicsof theresultingcandidatestandard, theOGCSensorThingsAPI,aretheuseofJSONasanencodingandRESTasabinding.

The resulting standards framework is basedon a RESTAPIwhich allowusers to performCREATE,READ,UPDATE,andDELETE(CRUD)actions.Thisfunctionalitycanbeappliedtotwomainfunctionalareas:

• SensingProfile:Thesensingprofiledefinesdifferentresourcestypes(includingdatamodel)forpublishingobservationdata.Thisfunctionality issimilartotheOGCSensorObservationService.

• TaskingProfile:The taskingprofiledefinesdifferent resource types forcontrollingsensors.ThisfunctionalityissimilartotheOGCSensorPlanningService.

Compared to the regular OGC SWE standards, the SWE IoT API is less comprehensive (e.g. nocomplexfeaturemodel,lessoptionsfortimestamping)sothatitcanberealisticallybeimplementedbylightweight,resource-constraineddevices.

Recently,theSensorThingsAPIstandardisationactivitieswerecompletedinafirstversion14.

MarineSWEProfileAmarineprofileoftheOGCSensorModelLanguage2.0(SensorML2.0)isbeingdevelopedallowingto provide metadata for different levels (e.g. observatory, instrument, and detector) and sensortypes. The latter will enable metadata of a specific type to be automatically inherited by alldevices/sensors of the same type. The application of further standards such as OGC PUCK willbenefit fromthisencoding, too,by facilitatingthecommunicationwith instruments.Fordeliveringobservationdata,theISO/OGCObservationsandMeasurements2.0(O&M2.0)standardservesasagood basis.Within anO&Mprofile, recommendationswill be given on needed observation typesthatcoverdifferentaspectsofmarinesensing(trajectory,stationary,orprofilemeasurements,etc.).Besides XML, further O&M encodings (e.g. JSON-based) will be considered. A profile of the OGCSensorObservationService2.0(SOS2.0)standardwillbespecifiedtoofferacommonwayonhowthis web service interface can be used for requestingmarine observations andmetadata. At thesametimethiswillofferacommoninterfacetocross-domainapplicationsbasedupontoolssuchastheGEOSSDAB.LightweightapproachessuchasRESTwillbeconsideredasfurtherbindingsfortheSOS interface. The profile will consider the existing observation systems so that migration pathstowards the specified profiles can be offered. We will present the current state of the profiledevelopment.Inparticular,acomparativeanalysisofSWEusageindifferentprojects,anoutlineoftherequirements,andfundamentalaspectsofprofilesofSWEstandardswillbeshown.

14http://www.opengeospatial.org/standards/sensorthings


23

FurtherRelevantStandards

IEEE1451

InFigure4themaincomponentsoftheIEEE1451standardapproachareillustrated.IEEE1451usesthetermtransducerinterfacemodule(TIM)torefertoasensororactuator,andanetworkcapableapplicationprocessor(NCAP)tomeanacontrollerinterfacingtooneormoreTIMs.Inthiscase,datacomingfromIEEE1451.X instrumentsareprocessedto injectdata intoan IEEE1451.0server.ThisserverpublishesdatausingtheHTTP1451standard.

Sensor

Actuator

IEEE1451.X

TIM1ton

IEEE1451.X

IEEE1451.0

HTTPServer

NCAP

IEEE1451Enable

Instruments

HostController

Figure4IEEE1451SystemArchitecture

Marine instrumentationmost commonlyuses serial links, so IEEE1451.2would apply. To simplifytheuseof IEEE1451forserial instruments, in2012anewdraftof IEEE1451.2hasbeenreleased.This new version of IEEE 1451.2 is fully compatible with an RS232 instrument, using thecommunicationandmeasurementservicesdescribed in IEEE1451.0.Thiswillallowmanufacturerstoimplementtheprotocolintheirnewgenerationofinstruments.

Another importantfeatureof IEEE1451applicabletomarine instrumentation isthedefinitionofastandard transducerelectronicdatasheet (TEDS). IEEE1451specifiesmanystandard templates fordescribing sensorsandactuatorswithaTEDS, and IEEE1451.4promotes the ideaof storingTEDSinformationwithin the device itself. The systemwe describe includes this approach aswell, withPUCKprotocolusedtostoreandretrievetheinstrumentdescription,whetherasanIEEE1451TEDS,or insomeother format. Javadistributeddataacquisitionandcontrol (JDDAC), createdbyAgilentTechnologies Inc. (SantaClara, CA,USA) and SunMicrosystems Inc. (RedwoodShores, CA,USA), isanotherrelatedeffortthatusedtheIEEE1451TEDS.

StandardCommandsforProgrammableInstruments(SCPI)

The Standard Commands for Programmable Instrumentation (SCPI) is an industry standard thatprovides software-level syntax and commands for operating instruments over IEEE-488, RS-232,EthernetandUSB[SCPI].Itsaimhasbeentopromoteacommonlanguageandsyntaxsuitableforallprogrammable instruments. Today, SCPI is supported by most of the manufacturers ofprogrammable instruments includingAgilent (HP), Tektronix, Keithley, Fluke, andRacal. SCPI is an


24

ASCII language that consists of configuration and query commands that are specific to theinstrument anda set of IEEE488.2operations and commands that are common to all SCPI-basedinstruments. SCPI commandshave long and short forms,where the long form is very descriptive,and the short form is an abbreviation: “TRIGGER:COUNT” can be “TRIG:COUN”. Although thisstandard is widely used in the industrial instrumentation, up to now themarine instrumentationmanufacturersdidnotadoptedthisstandardfortheirdevelopments.

CAN/CAN-OPENstandardfamily

ControllerAreaNetwork(CAN)wasoriginallydevelopedasabusarchitectureforautomobiles,buttoday isused inawidevarietyofapplications.TheCAN-busnetworkprovidesaveryefficientandrobust platform for deterministic real-time applications of distributed sensors and actuators. Keyadvantages provided by CAN-bus include robust and efficient error detection and messagetransmissionprotocols.CAN-busisbasedonOSIReferenceModellayers1and2(physicalanddatalink layers) and is standardized in ISO11898 [CAN]. Several application-level standardshavebeendeveloped to run on CAN-bus, notably the CANopen communication protocol and device profilespecification. Several oceanographic applications that use CAN-bus and CANopen for onboardcommunications have been implemented, including autonomous underwater vehicles and buoys,andatleastonemanufacturersuppliesoceanographicinstrumentsforCAN-bus.Animportantsteptowardsachievinginteroperabilitybetweendifferentoceanobservatorysystemsistouseabasicsetoftermstodescribethecollecteddata.Anumberofvocabulariesalreadyexist.However,CANopenstandardhasbeendefinedhavingdifferentapplications inmind.For instancetherearedefinitionsontheformatofelectronicdatasheetsthataredescribedwiththeCanOpenorOGC-SWEstandardsthat address similar specificationneedsbut arenot identical in format.Aharmonizationbetweenthese arrangements appears necessary for instance by defining a basic set of terms that can beeasilymappedbetweenthedifferentstandards.IntegrationofCANwithOGC-SWEstandardswillbepossible,e.g.by“mapping”CANopenelectronicdatasheetstoSensorML.

OGCPUCK

TheOGCPUCKisasimpleprotocolthatworkswithotherstandardstoenable interoperabilityandautomatic configuration. OGC PUCK makes it possible for instruments to carry information thatenablessensornetworkstousetheinstrumentanditsdata.OGCPUCKdefinesasimpleprotocoltostoreand retrieve information froman instrumentoverRS-232andEthernet [PUCK].As shown inFigure 5, this information consists of a minimal instrument datasheet that includes a universallyunique instrumentserialnumber,amanufacturer ID,andasmallamountofothermetadata.OGCPUCK protocol also allows an optional payload consisting of sensormetadata or any informationneededbyanobservingsystem.OGCPUCKcanbeimplementedininstrumentfirmwareaugmentingthe“native”instrumentcommandset.


25

InstrumentPayload

DatasheetRS232orEthernet

Figure5HostissuesOGCPUCKcommandstoretrievedatasheetandpayload

APUCK-enabledRS232instrumentcanoperateinan“instrumentmode”ora“PUCKmode.”Intheinstrument mode, the device responds to the protocol defined by its manufacturer, including“nonstandard” commands, while in the PUCK mode, the device responds to the standard PUCKprotocol.ThePUCKmodeistypicallyusedwhentheinstrumentisfirstconnectedtothehostorthehost is rebooted. To switch a PUCK-enabled device into the PUCK mode, a “PUCK soft break”commandissenttothedeviceatseveralbaudratesuntilavalidPUCKresponseisreceivedbythehostwhile in thePUCKmode, thehostcanretrievethePUCKdatasheetandanyoptionalpayloadinformation, fromwhich thehost can infer the instrumentmodeland themanufacturer.Thehostthen switches the device into the “instrument mode” and begins issuing instrument- specificprotocolcommandstoitasshowninFigure6.

TheOGCPUCKstandardspecifiesPUCKoverIP(“IPPUCK”).InadditiontothebasicPUCKprotocol,IPPUCKspecifiestheexistingZeroconfstandardasameanstoautomaticallyassigntheinstrument’slink-local IPaddressandhostname,andamechanismforhoststodiscoverthe instrumentaddressand“PUCKport”number.Thus,anIPPUCKinstrumentcanautomaticallyacquireanIPaddressandnamewhen it isphysically installed inanetwork.AhostcanthenuseZeroconf’sservicediscoveryprotocol to discover PUCK-enabled instruments in the marine IP network and retrieve theirmetadataandpayloadsusingPUCKcommandsissuedtotheinstrument’sspecified“PUCKport.

Instrument

Commandstoconfigure,acquire,etc..

Data

Figure6Basedoninforetrievedinthefirststep,hostusesinstrument’s“native”protocoltoconfigureandacquiredata.

Onekeyadvantageof implementingtheOGCPUCK is that thestandard it isalreadydevelopedbyseveralmarineinstrumentationmanufacturersanditenables inaveryeasymannertheautomaticinstrumentintegrationintosensornetwork(‘PlugandWork’)[SmartOcean],[SmartInterface].


26

3.7. ESONETYellowpagesAsreportedinFixO3deliverable2.8,theOpenOceanObservatoriesYellowPages’(O3YP’s)aimistoorganizetheinformationconcerningofftheshelfproducts,whichareprovidedbytheprivatesectorforthedevelopmentandmaintenanceofopen-oceanobservatories.

Thisincludesarangeofequipment,fromsimpleisolatedsensorparts,tocommunicationsystemsandevenintegratedobservatories.TheO3YP’salsoaimstoprovidefeedbackfromthescientificcommunityinwhatconcernstheexperiencewithaspecificproduct,addressingreliabilityforlong-termoperationsandtheuseinrealdeep-seaconditions.

AstheO3YPevolvedfromtheESONETYellowPages(EYP),whichwasmainlyfordeep---seaobservatories,theyneedtobeupdatedthroughseveralstepsbeforetheyarefullyfunctional.ThestepsforthisfirstupdatearedescribedinthisReport.TheinternetnamestaysasEsonetyellowpageshowevertheOpenOceanyellowpageswillbeanintegrationofEsonetYellowpages,JericoandEMSO.

Partoftheactivitiesintask2.6haveconsistedinlinkingtotheO3YO’stoautomaticallycreatecommercialsensortemplatesinordertoeasetheuseofthedevelopedSensorMLeditor.

Figure7ScreenshotoftheO3YPwebinterface,anupgradeoftheESONETYellowPages(EYP)

3.8. SWEandBestPracticesAsummaryofthebenefitsofSWEtechnologiesisprovidedintheFixO3HandbookofBestPractices:

“SensorWebtechnologiesmayclosetheinformationgapbetweensensordataproducersandsensordataconsumers.TheSensorWebalsoprovidesmeanstoremotelyoperatesensorsviathe


27

internetandtoprovideadditionalmetadatasuchasprovenanceorqualityinformation.Atthemoment,bestpracticesandcommonarchitecturestoutilizeSensorWebtechnologiesintheOceansdomainarebeinginvestigatedandimplementationsofthosearedeveloped.Thus,SWEmayeasetheworkofsensoroperators,domainscientistsandmodellers.”

Formoredetailswerefertothecorrespondingdeliverable[FixO3HandbookofBestPractices].

3. RESULTSANDDISCUSSIONThesectionpresentsthenewlydevelopedweb-basedsensorregistrationinterfaceinausermanualformat. The first section links to the source code repository, fromwhich the architecture canbederived.

3.1. SensorMLEditor(SMLE)sourcecodeTheeditorwasdevelopedunderanopen-sourceframework.ThecodeisavailableonGithubatthefollowingURL:https://github.com/52North/smle.FreeregistrationtoGithubmayberequiredtoaccesstherepository.

Figure8SMLEEditorsourcecode

3.2. SensorMLEditor(SMLE)ManualThis document provides helpful information on how to use the SensorML Editor (SMLE) Webapplicationprovidedby52°North. It uses a tutorial-basedmanner to guide you through thebasicfunctionalities. This documentation is based on the SMLE version from October 2016. The mostcurrentdevelopmentofSMLEisavailablefromtheofficialGitHubpageofSMLE.


28

3.3. BasicVisualInterfaceofSMLEThis section provides general information about the Web application SMLE. As the full nameindicates,theSensorMLEditorisaWebapplicationallowinguserstomanageSensorMLdocumentsof a preconfigured Sensor Observation Service (SOS). This SOS instance is configured duringinstallation by an IT-expert and is currently not changeable at runtime. SMLE provides a visualinterfaceforvarioustaskssuchasviewing/editing/deletingexistingSensorMLdocumentsorcreatingnew sensor descriptions. Without logging in, the application only allows to view existing sensordescriptions. Only after a successful login users may perform the administrative tasks create,edit/updateanddelete.TologinyoucanuseyourGitHubcredentials.

As an exemplar instance of SMLE, this guide uses the application fromhttp://pilot.52north.org:3000/#/.Thelandingpagegreetsyouasshowninthesubsequentfigure.

Figure9SMLEhomepage

ThedarkgreynavigationbarcontainstheavailablefunctionalitiesofSMLE,whichareaccessiblebyclickingthecorrespondingbutton.ViaNewandCreate fromTemplate,newSensorMLdocumentscanbecreated.UsingEdit/View,existingsensordescriptionscanbeviewedandedited.However,asmentioned above, the administrative functionalities can only be performed once logged in. Inconsequence, as a first step, you should log in via the login button located at the right of thenavigationbar.ThiswillopenapopupwindowtoenteryourGitHubcredentials.Notethatyoumayhavetoenablepopupswithinyourbrowser!


29

Figure10GithubCredentials

Aftersigning for the first time,youwillhavetoauthorizeSMLE,allowingtheapplicationtoaccessyour GitHub account. This step is not required for subsequent logins.When logged in, the loginbuttonisreplacedbyyourGitHubnameandtheoptiontologout.Inaddition,thenavigationbarisenrichedwithanewbuttoncalledDelete allowingyou todeleteyour sensordescriptions.Havinglogged in, all functionalities become available. Each is introduced subsequently within its ownsection.

3.4. ModifiableItemsandRestrictionsWhen logged in,youareable tocreate,editordeleteSensordescriptions.However,youareonlyallowedtomodifycontentthatyouhavepreviouslycreatedbyyourself.Tobemoreprecise,youareallowedtoviewanyavailablesensordescription fromanyuser.AlsoyoucancreatearbitrarynewSensorML documents, providing a new unique identifier. But you are not permitted toupdate ordelete sensor descriptions from another user. Only your own documents that are linked to youraccount are open for modification. Due to this restriction, the application prevents users tomanipulatecontentwithoutpermission.

Althoughnotbeingallowedtomodifydocumentsofotherusers,thevisualinterfaceallowstoeditanexisting sensordescriptionandevenclickon thePublish andUpdate buttons (see sectionEdityourownSensorMLDescriptionsformoredetailedworkflow).OnlythenSMLEwillnoticethatyoutried to change the description of another user and fail. This is due to technical reasons. As theunderlying SOS instance stores,which sensor descriptionwas createdbywhich user,SMLE buildsand executes a SOS UpdateSensorDescription request. If the logged in user does not have thepermissiontoupdatethatspecificsensordescription,theSOSoperationfails.Asanenhancement,future version of SMLE might inspect earlier, whether users have permission to edit a certaindocumentandinformthemviasuitablemeans(e.g.hidetheeditbuttononamissingpermission).


30

3.5. CreateSensorMLDocumentfromTemplateYouneedtobeloggedininordertopublishanewSensorMLdescription.

FindandSelectTemplateTheapplicationallowscreatingnewsensordescriptionbasedonanexisting template thatalreadyfillspartsoftheSensorMLstructure.SelectCreatefromTemplatefromthenavigationbartoopenanewmenu where you can browse and search for available SensorML templates provided by theESONETYELLOWPAGES.AsofOctober2016380templatesareavailablethatcanbefilteredthroughappropriatekeywords.Tobrowsealltemplates,simplyhittheSearchbuttonwithoutanykeyword.Tofilterthetemplates,enteranykeywordandhittheSearchbutton.Thefollowingexampleshowsallentriesforthekeywordsalinity.

Fromthe listof returned templatesyoumayselect the target template,which isused tocreateanew SensorML document. E.g. when selecting the template Hydrolab Conductivity Sensor, adescription of the selected sensor as well as the option to create a sensor description of thistemplate is provided. Optionally, you may already enter a new unique identifier for the newSensorMLdocument,eithermanuallyorbyclickingtheCreateidentifierbutton,whichgeneratesasystem-wideuniqueidentifier.However,theidentifiermaybedefinedlateraswell.

Figure11SMLEtemplateselection

InstantiateandEditnewSensorMLDocumentbasedonselectedTemplateAfterselectingatemplate(andprovidinganewidentifier)youmayclickonthebuttonCreatesensordescription from template. This will instantiate a new SensorML document using the selectedtemplatetoprovidethenecessarySensorMLelementsandinsertpredefinedvalues.Theapplication


31

switchestotheeditview,wheretheelementsoftheSensorMLdocumentaredisplayed.Ontheleftside,theeditviewallowstoaddnewmetadatawithinvariouselementsofthesensordescriptionoreditexistingproperties.Ontherightside,youmaytogglethetreeviewtogainanoverviewofthespecifiedmetadataasatreestructure.

Figure12SMLEinstantiation

If specified, thevalueof thesecondentry Identifier stores theunique identifier,whichcanstillbemodified.Optionally, you can activate the expanded viewofall available elements by setting thecheckboxofShowall locatedat thetopof theeditwindow. Ifactivated,additionalelement fieldsarerevealedtobeedited.

Theprocessofaddingnewinformationusesanestedwindowdesigntoresemblethehierarchyofthe added item. As an example, the subsequent series of figures shows how to add contactinformation.Noticehowwitheachnewhierarchy levelanewnestedwindowappears,whereyoucanadd/enternewinformation.Tocloseanestedwindows,youmayeitherusetheClosebuttononthetoprightofthewindoworclickontheverticallyorientednameofaprevioushierarchyelementontheleft.

1 Navigate to the Contacts element of the SensorML document. Click on the Add button,whichaddstheitemContactlist.


32

Figure13SMLEinstantiation-step1

2 ClickonthenewlycreatedContactListelementtoopenitinanewnestedwindow.


33


3 ClicktheAddbuttontocreatethenewitemResponsibleparty.


34


4 ClickonResponsiblepartytoopenandedititinanewnestedwindow.


35


5 FilltheformfieldsoftheResponsiblepartyelementand,inadditionclickonCreateContactInfo, which adds a new item called Contact Info. Whenever you edit any form field, thecorresponding content is immediately updated with the new value. Switching back toprevioushierarchylevel(inthiscasePhysicalSystemorContactList)isallowedatanytime.AllchangedvalueshavebeenrecognizedandappliedbySMLE.


36


6 ClickonContactInfotoopenandedititinanewnestedwindow.


37


7 When you reach this point, you should have understood, how to edit the properties of aSensorML document using SMLE. Entries highlighted using blue colour reveal editableproperties within a new nested window. Form fields represent the values of a certainproperty. E.g., within the Contact element, there are three additional elements and twoform fields to be edited. Within this guide only the Address element is configuredsubsequently.Soclickonittoopenitasanewnestedwindow.


38


8 Fillout the form fieldsof theAddress elementwithyourvalues.Ofparticular interestarethefieldsDeliverypointandE-mail.BothhaveadditionalinteractionscalledAddandClear.TheClearbuttonclears theenteredvaluewhile theAddbuttonmustbeclicked topersisttheenteredvalue for theproperty.As thesespecificpropertiesallowmultiplevalues, it isnotsufficienttoonlyenterthenewvaluewithintheformfield.Insteadyouhavetoexplicitlyaddit.


39


9 AfterexplicitlyaddingthevaluesofDeliverypointandE-mail,youmayenterasecondvalueorremoveanyvalue.


40


10 To finishediting the contact info youmayeitheruse theClose buttonwithineachnestedwindow (located on the top right) or click on the vertically oriented name of a previoushierarchylevelontheleft.Usingthelatter,youmaydirectlyreturntotheleftmostwindow(in this casePhysical System),which is the top-levelof theSensorMLDocument. Toverifytheappliedchangesyoumayuse the tree viewon the rightandexpand itat the relevantelements.Alternativelynavigatetotherespectiveelementwithintheleftmenutoinspectitandperformadditionaledits.


41


11 At this point, you should have the knowledge to edit any property of the SensorMLdescription.Youmayaddnewelementsoreditthevaluesofacertainelementinanestedwindow.Clickingonanyitem,whichishighlightedusingbluecolour,willopenthatelementasanewnestedwindowtoreflectthehierarchyoftheSensorMLdocumentstructure.

PresetStructureandValuesoftheTemplateAsyoumayhavenoticed,whenusingatemplatecertainelementsarealreadypre-setwithvaluesfrom the template. While some values represent template-specific standard values that do notrequirechanges,certainotherelementsareinstantiatedusingnullvalues.However,whenrelyingonthe template, you should have the knowledge to identify those elements and provide suitablevalues.

Asanexample,usingtheHydrolabConductivitySensor template, theClassificationelement ispre-setwithcertainclassifiers.OpenthiselementbyclickingonClassifierlist(...).


42

Figure23Replacing/Overridingvalues1

Thiswillrevealanestedwindowwithallpre-setclassifiersofthetemplate.Asyoucansee,thevalueof most of the classifiers is set to null or -. However, as they describe important operationalcharacteristics of the chosen sensor, you should fill them with applicable real values. Toreplace/overrideanyvalue,clickonthecorrespondingitem.E.g.clickonOperatingdepthtoopenitinanewnestedwindow.


43


Withintheeditwindowyoumightchangethelabelandinparticularthevalueofthedisplayeditem.Assoonasyoureplacethevalueproperty,youmayclosetheTermeditwindow.


44


Backon thehierarchy levelClassifier list youshouldverify that theeditedproperty indeedcarriesthenewvalue.


45


Asshownbythissimpleexample,youshouldnavigatethroughallpre-setvaluesandedit themtothe de facto values of the sensor for which you create the SensorML document. SMLE willNOTinformyouaboutanypropertythatstillcarriesanynullvalues.Soyouwillhavetocarefullyinspecteachpropertybyyourself.Shouldyouwishtoremoveanyproperty,youarefreetodoso.Basingona template is up to your choice and only provides recommendations on how to model sensordescriptions using the SensorML standard. In theory, you are free to include the necessaryinformation about your sensor using other properties/elements of SensorML. However, usingtemplates and its recommended pre-set properties allows better comparability to descriptions ofsimilarsensors.

3.6. PublishandpersistnewSensorMLDocumentAfteraddingoroverridingthenecessarypropertiestoreflectyousensorcharacteristics,clickonthePublishDescriptionbutton locatedbelowtheeditwindow.Note thatyouhavetobe logged in toseethebutton!Ifyouhavenotspecifiedanyidentifierforthenewdocumentyouarepromptedtoenter it now.Again, youmay let the systemgenerate anew identifier using theCreate identifierbutton,asshowninthesubsequentfigure.Alternatively,enteramanualvalue.


46

Figure27Publishnewsensorinstance1

When publishing the document, SMLE will provide you with a final uneditable view of the XMLstructureof thenewSensorMLdocument forverificationpurposes.Hereyoushouldproofreadalltheeditedproperties/elements.Whendetectinganerrororsomeotherreasontoreturntotheeditview, use the Edit Description button located above the XML view. If you are satisfied with thepreview of the new SensorML document, you find a notification below the XML preview. SMLEcontacts the SOS instance to check,whether the identifier of the new SensorML instance alreadyexistswithintheSOS.Ifnot,itinformsyouaboutthisandoffersyouabuttoncalledAddDescriptiontopersistthecreateddocumentwithintheSOS.


Afterclickingthebutton,youarenotifiedwhethertheprocesswassuccessful.(e.g.notethesuccessmessageat thebottomof the following figure.Occurringerrorsaredescribed insub-sectionErrorHandlingbelow.)


47


ShouldtheidentifieralreadyexistwithintheSOS,YouareaskedifyouwanttoupdatetheexistingdocumentusinganUpdateDescriptionbutton.Hereyoushouldcarefullydecidewhattodo.Ifyoucreated a new SensoML instance for a new sensor, the identifier should be new as well. If youreceiveanotificationthatthe identifieralreadyexists,youshouldeditthedocumentandaltertheproperty.



48

Once persistedwithin the SOS, you are still able to edit the document using theEditDescriptionbutton and re-publish the document. In this case the identifier should remain untouched to onlyupdatetheexistingdocumentwithintheSOS.

3.7. ErrorHandlingWhen trying to publish a SensorML document, the underlying SOS might return with an errormessage in case the SensorML document does not conform to the requirements of the SOS andSensorML standard. An error message may have several reasons. To mention a few: a neededelementmaynotbespecified,emptyelementsmaynotbeallowedorprovidedpropertyvaluesdonot pass validity checks. If the SOS rejects the SensorML document for whatever reason, SMLEdisplaystheerrormessageatthebottomofthepublishview,accordingtothenextfigure.

Figure31Errorhandling1

Currently,thedisplayederrormessageisforwardedfromtheSOSinstanceandshouldindicatewhatkindoferroroccurs.Hopefully,themessagecontainsahintonhowtoedittheSensorMLdocumenttomake it valid. In this case the errormessage notifies you of amissing required element calledlinkagewithinthehigher-levelelementCI_OnlineResource.Sadly,thereisnoindicationonwheretofindthelatter.Totroubleshoottheprobleminworstcasescenario,editthedocumentandinspecteveryhierarchyleveltofindtherequiredelementandprovideapropervalueforit.Forinstance,thecreated Contact element defines an element Online Resource with the property Linkage. So,navigate toContact List - Responsible Party - Contact (Contact Info) - Online Resource to enter asuitablevalue,asshowninthefollowingfigure.


49

Figure32Errorhandling2

After that hit thePublishDescription button again to open the publish view and add/update thenewsensordescription.Ifnoothererroroccurs,theSOSwillthensavethetransmitteddocument.

3.8. CreatenewSensorMLDocumentIn contrast to creating a new SensorML instance using a template, you are free to create acompletely new document via the menu New from the navigation bar. As first step you arepromptedtochoosethedescriptionTypeof thenewdocument instance.CurrentlyyoucanchoosebetweenPhysicalSystem for single sensor devices andPhysicalComponent for sensor componentswithinamultisensorcomponent-basedsetting.

Figure33Createnewsensor1

After selection you enter the edit view, where you can add necessary sensor information usingdedicated elements and properties of the SensorML standard. The process of adding/editing


50

information aswell as the process of publishing the document has already beendescribed in theprevioussectionCreateSensorMLDocumentfromTemplate.Thus,itisskippedhere.

Figure34Createnewsensor2

Asyounotice, thecreateddocument isstillempty,asyoustarteditingfromthescratch.Whetheryoudecidetoeditanemptydescriptionorbaseonanexistingtemplateisuptoyou.However,itisrecommendedtostartusingatemplate,ifpossible.Thepre-setstructuregeneratedbythetemplatemayallowbettercomparabilitybetweensimilarSensorMLdocumentsofsimilarsensorsettings.

3.9. ViewexistingSensorMLDescriptionsTo view existing sensor descriptions, you do not have to be logged in. Navigate to the menuEdit/ViewfromthenavigationbartofindadropdownwiththeavailableSensorMLdocuments.

Figure35Viewingsensorinstance1


51

After selecting a certain document, SMLE provides you with a collapsed tree structure of theelementsoftheSensorMLdocument,asshowninthesubsequentfigure.


You can inspect each elementwith a leading horizontal arrowby clicking on it to reveal the nextlevelofthetreestructure.Leafnodevaluesaremarkedusingorangecolourandsurroundingquoteswhile attribute values are marked using blue colour. Alternatively, the XML equivalent of theSensorMLdocumentcanbeviewedbyswitchingtotheasXMLtab.


52


BelowbothviewsyoufindtwobuttonsEditsensordescriptionandcopysensordescription.Whiletheformerallowsyoutoedittheexistingdocument(asidentifiedbyitsuniqueID)thelattercreatesacopyofthecurrentlyselectedSensorMLinstancebutremovesitsuniqueidentifier,causingyoutoprovideanewidentifierwithintheeditview.Notethatalthoughyoumightnotbeloggedin,youstillseebothbuttonsallowingyoutoswitchtothecorrespondingviews.

3.10. EdityourownSensorMLDescriptionsYouneedtobeloggedininordertoeditanexistingSensorMLdescription.Alsoyouareonlyallowedtoeditsensordescriptionsthatyouhavecreatedwithyouraccount.

ToeditapreviouslycreatedSensorMLdocument,clickonthemenuEdit/Viewfromthenavigationbarandselecttheidofthedocumentyouintendtoedit.Thiswillprovideyouwiththeviewwindowasalreadydescribedintheprevioussection.ToeditthedocumentclickonEditsensordescription,whichopenstheeditview,whereallstoredinformationoftheselecteddocumentisdisplayed.Hereyou can apply changes like add missing information or override/remove existingelements/properties.TheprocessofeditinghasalreadybeendescribedinsectionCreateSensorMLDocumentfromTemplateandisskippedhere.Pleaserefertothatsectionfordetails.Aftereditingyoucanre-publishthedocumentbyupdatingthedocumentusingthesameidentifier.

RoleoftheuniqueIdentifierEachSensorMLdocumentstoredintheSOSisreferencedbyitsuniqueidentifier.Whenyouintendto only update an existing sensor description, it is vital that you leave the identifier untouched.


53

When you change it and then publish the document, you will create a whole new additionaldocument, under the assumption that the new identifier does not exist yet. In a worse case themodified identifier referencesadifferentexistingSensorML instancedescribingadifferent sensor.As a consequence, you should always carefully check the identifier property and associatednotificationmessagesofSMLEtopreventfalsepublishingofadocument.

3.11. RestrictiontoonlyedityourownContentYouareenabledtoviewandeditanyavailableSensorMLdocumentoftheunderlyingSOS.However,when trying to re-publish/update a modified SensorML document, which is not linked to youraccount, SMLE will inform you that you miss the appropriate permission, as the underlying SOSrejectstheupdatefromthenon-authorizeduser.

Figure38Editsensorinstance

As a result, you are only allowed to update sensor descriptions that you have createdwith yourcurrentaccount.Tostillsavethemodificationsofacertainsensordescription,forwhichyoudonothavethesufficientpermission,youmightchangeits identifierandthuscreateanadditionalsensordescription.Mindthatthisprocesspreservestheoldsensordescriptionandcreatesamodifiednewversion using a different identifier. Whether this approach is applicable is up to you and yourworkingenvironment.

3.12. DeleteyourownSensorMLDescriptionsYou need to be logged in in order to delete a SensorML description. Also you are only allowed todeletesensordescriptionsthatyouhavecreatedwithyouraccount.


54

TodeleteapreviouslycreatedsensordescriptionyouhavetonavigatetomenuDelete.Notethatthismenu is only available after successful login.Within the delete view, you choose the desireddocumentviaadropdownlist.

Figure39Deletesensorinstance1

AfterselectionyouseetheXMLstructureoftheselecteddocument.Inspectittoverifythatthis isthedesireddocument,whichshouldbedeleted.Byclicking theDeletesensordescriptionbutton,you will irretrievably delete the document! SMLE will not prompt you with an additionalconformationrequest.


Asaresult,thedocumentisdeletedfromtheunderlyingSOSandSMLEdisplaysasuccessmessage.



55

3.13. RestrictiontoonlydeleteyourownContentSimilar to the restriction of editing your own content, you are also only authorized to delete anySensorML document that is linked to your current account. You are not allowed to delete thedescriptionsofanotheruser.

4. CONCLUSIONSANDOUTLOOK

The Sensor Web Enablement (SWE) framework shows potential in delivering a new method forharmonization of ocean observing systems. Because several initiatives are willing to test theframework, there is a critical need to develop and test tools for real-world implementation. Thisstartswith theproper registrationof sensors, inSensorML format,which is thebasis forallotherSWE services in the framework. A user-friendly editor (SMLE, see above picture) was thereforedeveloped, which has consisted in the core of the reported work. The document includes anexhaustiveusermanualinordertofosteritsuseacrossthecommunity.

SMLEisopensourceandisavailableatthefollowingURL:• https://github.com/52North/smle

ItslatestdeploymentfordemonstrationisavailableatthefollowingURL:• http://pilot.52north.org:3000/#/templates

NextstepsincludethedevelopmentofalinkwiththeFixO3portal’sobservatoriessectiontoavoidmultiplicityofaccesscredentials(unifyingbothresources)andtostarttestingtheinterfacewiththeuser community in FixO3. From the received feedback necessary changes will be implemented(version1.0).

5. REFERENCES

[CAN] ISO11898-1:2003Roadvehicles—Controllerareanetwork—Part1:DatalinklayerandphysicalsignallingISO11898-2:2003Roadvehicles—Controllerareanetwork—Part2:High-speedmediumaccessunit

ISO11898-3:2006Roadvehicles—Controllerareanetwork—Part3:Low-speed,fault-tolerant,mediumdependentinterface

ISO11898-4:2004Roadvehicles—Controllerareanetwork—Part4:Time-triggeredcommunication

ISO11898-5:2007Roadvehicles—Controllerareanetwork—Part5:High-speedmediumaccessunitwithlow-powermode

ISO11898-6:2013Roadvehicles--Controllerareanetwork(CAN)--Part6:High-speedmediumaccessunitwithselectivewake-upfunctionality


56

[IEEE1451] StandardforaSmartTransducerInterfaceforSensorsandActuators—CommonFunctions,CommunicationProtocols,andTransducerElectronicDataSheet(TEDS)Formats,IEEE1451.0,IEEE,2007.

[ISO] InternationalOrganizationforStandardization(ISO),“ISO19115metadatastandardforgeographicinformation,”Jul.25,2011[Online].Available:http://www.iso.org

[O&M2.0_ISO] Cox,Simon(2011).OGCImplementationSpecification:ObservationsandMeasurements(O&M)-XMLImplementation2.0(10-025r1).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[O&M2.0_OGC] Cox,Simon(2011).OGCImplementationSpecification:ObservationsandMeasurements(O&M)-XMLImplementation2.0(10-025r1).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[OGC-Architecture] M.Botts,G.Percivall,C.Reed,andJ.Davidson,“OGCsensorwebenablement:Overviewandhighlevelarchitecture,”inGeoSensorNetworks,ser.LectureNotesinComputerScience.Berlin,Germany:Springer-Verlag,2008,pp.175–190.

[PUCK] T.O’Reilly,“OGC®PUCKProtocolStandard,”OpenGeospatialConsortium(OGC),Wayland,MA,USA,OGCCandidateEncodingStandard09-127r2 ,2014[Online].Available:http://www.opengeospatial.org/standards/puck

[SCPI] ANSI/IEEE488.2IEEECodes,Formats,Protocols,andCommonCommands,andStandardCommandsforProgrammableInstruments

[SDI] L.Strain,A.Rajabifard,I.Williamson:Marineadministrationandspatialdatainfrastructure,MarinePolicy,30(4)(2006),pp.431–441

[SensorML2.0] Botts,MikeandAlexandreRobin(2014).OGCImplementationSpecification:SensorModelLanguage(SensorML)2.0.0(12-000).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SES] Echterhoff,JohannesandThomasEverding(2008).OGCDiscussionPaper:OGCSensorEventService(SES)0.3.0(08-133).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SID] Bröring,ArneandStefanBelow(2010).OGCDiscussionPaper:SensorInterfaceDescriptors(OGC10-134).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SmartOcean] D.M.Toma,T.O’Reilly,J.delRio,K.Headley,A.Manuel,A.Bröring,andD.Edgington,“Smartsensorsforinteroperablesmartoceanenvironment,”inProc.IEEEOCEANSConf.,Santander,Spain,Jun.6–9,2011,DOI:10.1109/Oceans-Spain.2011.6003654.


57

[SOS2.0] Bröring,Arne,ChristophStaschandJohannesEchterhoff(2012).OGCImplementationSpecification:SensorObservationService(SOS)2.0(12-006).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SOSHydrology] GEOWOWConsortium(2014).OGCDiscussionPaper:OGCSensorObservationService2.0HydrologyProfile(OGC14-004).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SOSLight] Jirka,Simon,ChristophStaschandArneBröring(2011).OGCDiscussionPaper:LightweightSOSProfileforStationaryIn-SituSensors(OGC11-169).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SPS2.0] Simonis,IngoandJohannesEchterhoff(2011).OGCImplementationSpecification:SensorPlanningService(SPS)2.0.0(09-000).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SWECommon2.0] Robin,Alexandre(2011).OGCImplementationSpecification:SWECommonDataModel2.0.0(08-094r1).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[SWEServiceModel2.0] Echterhoff,Johannes(2011).OGCImplementationSpecification:SWEServiceModel2.0.0(09-001).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[WaterML2.0] Taylor,Peter(2012).OGCImplementationSpecification:WaterML2.0:Part1-Timeseries(0-126r3).Wayland,MA,USA,OpenGeospatialConsortiumInc.

[FixO3HandbookofBestPractices]

L.Coppola,M.Ntoumas,R.Bozzano,M.Bensi,S.Hartman,M.CharcosLlorens,etal.,"FixO3HandbookOfBestPractices,"2016.

6. ACRONYMS

FixO3: FixedpointOpenOceanObservatoriesNetwork

SDI:SpatialDataInfrastructure

IEEE:InstituteofElectricalandElectronicsEngineers

OGC:OpenGeospatialConsortium

ISO:InternationalOrganizationforStandardization

O&M:ObservationsandMeasurements

SOS:SensorObservationService


58

SML:SensorModelLanguage(SensorML)

TML:TransducerMarkupLanguage

SPS:SensorPlanningService

ODIP:OceanDataInteroperabilityPlatform

IOOS:IntegratedOceanObservingSystem

EMSO:EuropeanMultidisciplinarySeafloorandWaterColumnObservatory

ESONET:EuropeanSeasObservatoryNetwork

NeXOS:NextGenerationWeb-EnabledSensorsfortheMonitoringofaChangingOcean

O3YP’s:OpenOceanObservatoriesYellowPages(a.k.aESONETYellowPages)

SMLE:ThenewlydevelopedSensorMLEditor,pronounced“SMiLE”

fixo3 d2.10v1.0 finaldata products in a fairly automated way, i.e. without the often error-prone...

Documents