We present the Coloured Petri Nets (CPNs) modelling of the SmartOcean platform currently under development and aimed at providing cloud-based services for data-driven software systems and applications relying on marine data. The CPN model captures the systems-of-system architecture and the platform services, and is intended to evolve as a formal foundation along-side the implementation of the platform and its services. The CPN model encompass data-, messaging-, security-, and edge integration services with a focus on providing an abstract modelling of the service and system interaction. As part of the modelling work, we provide some general CPN patterns for system-of-systems modelling and service provision, consumption, and interaction.
Smart systems driven by the Internet-of-things (IoT), sensor- and actuator technology, and data
analytics are becoming pervasive across all domains including energy, transportation, buildings,
and homes [
Obtaining marine- and ocean data of suficient quality for use in smart systems represents
significant challenges due to the enormous geographical areas, the hostility of the ocean
environment, accessibility for deployment and service of equipment, severe limitations in
communication capabilities and availability of power. While ocean- and marine data services
are now emerging, there is a huge gap in data coverage and there are currently substantial
technology challenges related to interoperability, data- and meta-data standards, and APIs [
SFI Smart Ocean [
The focus of this paper is on the Smart Ocean platform which constitute the data and
application service layer. The platform is envisioned as an integration platform for the systems
that constitute the Smart Ocean digital ecosystem, and will be based on software components,
APIs, cloud platform services and containers for developing and deploying applications and
services. As a first step towards development of the platform, we have undertaken an extensive
study based on stakeholder- and focus-group interviews with the aim of identifying requirements
and challenges pertinent to the development of the platform. The results from the study were
published in [
DP DP_MSG
DS DC_MSG
SmartOcean Platform SOPlatform
EDS EDS_MSG
GW GW_MSG
External
DataServices ExternalDataServices
Underwater
WSNs UWSNs that can serve as an evolving sound foundation during our research and development work on implementation of the platform. CPNs are suitable for this purpose as: 1) the hierarchical organisation into modules allows us to capture the system architecture at diferent levels of abstraction; and 2) the executability of the models allows us to capture the behavioral aspects related to the interactions between its constituent subsystems and services. The contribution of this paper is to present the constructed CPN model focussing on system architecture and service interaction, and how it constitutes an abstract conceptualisation of the platform.
The rest of this paper is organised as follows. Section 2 presents the CPN model of the system architecture and the platform services while Section 3 presents the modelling of the data services which are at the core of the platform. The modelling of data providers and consumers are presented in Section 4. Section 5 concentrates on the modelling of the (external) data consumers and providers. Sections 6 and 7 present the edge integration service and the security services, respectively. Finally, in Section 8 we sum up the conclusions and present direction for future work. The reader is assumed to be familiar with the basic concept of high-level Petri nets and the CPN modelling language.
1`(DataService,DP_DATA(DP(2)))++ 1`(MessageService,DP_PUB(Topic(1)) ) 2 In DP
DP_MSG Out DC 1
DC_MSG 1`(MessageService,DC_SUB((Topic(3) ,DC(2))))
DataService
Data Service 1`(SecurityService,SS_REQ([SS_AUTH EN_REQ]))
EIS 1 SS
SS_MSG Security
Service SecurityService
EIS_MSG
EdgeIntegrationService
Edge Integration Service 1`(DataService,EDS_DATA) 1 EDS In
EDS_MSG 1`WSN_DATA(SENSOR(2))++ 1`WSN_DATA(SENSOR(3)) 2 GW In/Out
GW_MSG
Kognifai [
Figure 3 shows the submodule of the SmartOceanPlatform substitution transition in Figure 2. The port places in Figure 3 are associated with the accordingly named socket places in Figure 2. The security service is an internal service providing authentication and authorisation services to the data- and edge integration service as represented by the SS (security services) place. The edge integration services (EISs) constitute the service for interaction with the UWSNs via the GW (gateway) place, and is able to provide data to the data service as modelled by the EIS place. The edge integration service (EIS) is a distinct service of the platform and provides data and control integration with underwater sensor networks to support edge computing on smart sensors and sensor communication hubs. The need for edge computing and smart sensors is grounded in the use of acoustic communication where low communication bandwidth induces the need for local processing and fine-grained control on the sensor data being communicated. The data service has interaction points with the external data systems (EDSs) (place EDS) and the smart ocean data providers (place DP), and the data consumers (place DC).
The port places in Figures 2 and 3 all represent points of service interaction in the platform, and tokens present on these places are then representing request and response messages sent to and from the services. The colour sets used in the places representing points of service interaction is given in Figure 4. A central aim of our modelling approach has been to develop a CPN model which in a compact manner can represent the subsystems and the services constituting the platform, and which is parameterised wrt. to the number of data producers, data consumers, and sensors. The Component colour set is an enumeration colour set with a value for each of the kinds of subsystems on the platform. This colour set is used as the first component in all the _MSG product colour sets of the port places in Figures 2 and 3. The first colset Component = with DataService | SecurityService | MessageService | DataConsumer | DataProvider | ExternalDataService; (* --- data producers --- *) colset ID_DP = int with 1..DP_N; colset DP = union DP : ID_DP; colset DP_Message = union DP_DATA : DP + DP_PUB : TOPIC; colset DP_MSG = product Component * DP_Message; (* --- data consumers --- *) colset ID_DC = int with 1..DC_N; colset DC = union DC: ID_DC; colset DC_Message = union DC_DATA : DC + DS_DATA_REQ : DC +
DC_SUB : TopicxDC + DC_UNSUB : TopicxDC; colset DC_MSG = product Component * DC_Message; (* --- external data services --- *) colset EDS_Message = union EDS_DATA + EDS_DATAREQ : DC + EDS_DATARESP : DC; colset EDS_MSG = product Component * EDS_Message; colset GW_MSG = union WSN_DATA : Sensor (* --- edge integration service and gateway --- *) colset ID_SENSOR = int with 1.. SN_N; colset Sensor = union SENSOR : ID_SENSOR; (* --- edge integration service --- *) colset EIS_Message = union EIS_DATA : Sensor + EIS_PUB : TOPIC; colset EIS_MSG = product Component * EIS_Message; (* --- security service --- *) colset SS_REQUEST = with SS_AUTHEN_REQ | SS_AUTHOR_REQ ; colset SS_REQUESTS = list SS_REQUEST; colset SS_Message = union SS_REQ : SS_REQUESTS + SS_Response; colset SS_MSG = product Component * SS_Message; component of a token of these colour sets is used to model where the corresponding message is situated. The general modelling pattern applied here is that colour sets ending in _Message are used to model the messages that can be interchanged with the service in question, and this colour set is then used in the _MSG colour set where the component part is added.
The marking shown in Figure 3 corresponds to a state in which there are two messages sent from the data providers to the data service providing data to the data service and publication of data on topic 2 in the messaging service. A data consumer has sent a request to subscribe to topic 3 in the messaging service. In addition, the external data service is providing data, and there are two data messages coming to the edge integration service from sensors 2 and 3. A request message has also been sent to the security service for authentication.
Data services are services that performs computation on data ingested on the platform. Its
subcomponents (e.g. microservices), can have diferent functional requirements such as cleaning,
validation, or curation of data. Such sub-components can be found in typical big data processing
architectures as the one proposed by NIST [
The platform provides two fundamental data services as shown in Figure 5 where the port places are linked to the accordingly named socket places in Figure 3. The DataSpaceService substitution transition represents a service for data intended for long-term storage which can then be provided to consumers that have a need for accessing historical data. The MessagingService is a data service for real-time provision of data streams. It should be noted that in the present version of the platform, data from external systems is only provided via the data space service. We present modelling of the two data services in further detail in the following subsections.
DP In
DP_MSG
DC Out
DC_MSG
SS In/Out
SS_MSG
EIS In
EIS_MSG
EDS In
EDS_MSG DataSpaceService
Data Space Service Messaging
Service MessagingService
ProcessProviderData is a service concerned with processing of incoming data from a data provider.
EDSProcessData is a service concerned with processing of incoming data from an external data service.
ConsumerProcessRequest is a service handling data requests from data consumers. This substitution transition is connected to the EDS place as handling a data request may involve fetching the data from an external data service for which the data space service is acting as a proxy.
EIDProcessData is a service handling data coming via the edge integration service. This service is not connected to the SS as the authentication and authorisation related to the edge integration service is handled within the edge integration service.
We do not go into detail with the modelling of all four subservices of the data space service, but consider only the most complex one which is the ConsumerProcessRequest module in Figure 7. In EIS
EIS_MSG (DDaS[t_aaDuSteAhrTevAico_erRe,ElsQe(dacu)t)hr]AuthSReenqdues(SStSe(_cDuRDraESittQ_ayD(SSSeAeSrrTvv_AiiRcc_eeeR,q,EuQe(sdt(ca))uthe,aWuAatSuhitStrih)n)g)InD/CO(DD_uSMat_tSaDGSAeTrAvi_cRe,EQ(dc)) AutRheRcees(ipSvSoeeSnc_sueRrietyspSoenrvsiec)e,
SS_MSG In/Out DC (ExternalDataService,
EDS_DATAREQ(dc)) EDS In/Out
EDS_MSG (ExternalDataService, EDS_DATARESP(dc))
The processing of a data consumer request will first proceed with authentication and/or authorisation as modelled by the SendAuthRequest and ReceiveAuthResponse transition which invokes the security service via the SS place in order to perform this part of the operation. If the data space service stores the data itself, the request will be handled directly and a response sent back as modelled by the SendDataResponse transition. If the data request is to be handled via an external data service, then the request will be forwarded by the data space service as modelled by the EDSDataRequest transition. In that case, the data space service will be Waiting for a response from the external data service before a response to the request is being sent back to the consumer as modelled by the EDSDataResponse transition. The marking shows a state in which a request is being processed from data consumer 1 and there is now a choice as to whether this request will be handled internally by directly sending a data response or whether it will be handled by sending a request to the external data services.
DP
IDnP_MSG Out DC subs EIS In
EIS_MSG EIS Publish (MessageService,
EIS_PUB(topic))
InitSubscriptions() Subscriptions 1 ]1)`,([(TTooppicic((31),)[,][)D,C(T(o1p),iDc(C4()2,[)]]))],(Topic(2),[
Subscriptions (MessageService, DC_UNSUB(topic,dc))
Process subs
Unsubscribe Unsubscribe (subs,topic,dc) unsubscribe to topics and efectively consists of removing the subscribing data consumer from the list of subscribers on the topic. The processing of a subscribe request is more complex and it requires interaction with the security service in order to check, for instance, that the data consumer are authorized to subscribe the topic and in that way received data published on the topic. This is modelled by the ProcessPublish module shown in Figure 9 which is the submodule of the ProcessSubscribe substitution transition in Figure 8.
It is important to note that the messaging system provides a highly flexible scheme and can be used to implement many diferent data processing pipelines. As example, subscribers may process and transform the data and republish it again (possibly on other topics) or a subscriber may store the data in the data space service by acting both as a data consumer and data provider. colset ID_TOPIC = int with 1..TOPIC_N; colset TOPIC = union Topic : ID_TOPIC; colset TopicxDCs = product TOPIC * DCs; colset Subscriptions = list TopicxDCs; colset TopicxDC = product TOPIC * DC; fun InitSubscriptions () = List.map (fn t => (t,[])) (TOPIC.all()); fun Subscribe (subs, topic, dc) =
List.map (fn (t,subscriptions) => if (t = topic) andalso not (List.exists (fn dc’ => dc = dc’) subscriptions) then (t,dc::subscriptions) else (t,subscriptions)) val consumers = case (List.find (fn (t,_) => t = topic)) subs of
NONE => [] | SOME (_,subscribers) =>
List.map (fn dc => (DataConsumer,DC_DATA(dc))) subscribers fun Publish (subs, topic) = let subs subs in end;
consumers fun Unsubscribe (subs, topic, dc) =
List.map (fn (t,subscriptions) => if (t = topic) then (t,List.filter (fn dc’ => dc <> dc’) subscriptions) else (t,subscriptions))
Consumers
DC.all() dc DC Data Providers dc dc
dp DP.all() DP dp
Receive
Data Subscribe Unsubscribe
When it comes to the data consumers then they may receive data as modelled by the ReceiveData transitions either via the data space service or the messaging service. In addition, the data consumers may subscribe and unsubscribe to topics in the messaging service as modelled by the Subscribe and Ubsubscribe transitions, respectively.
For the platform to serve as an integration point for applications and composite data services, there is a need to also provide access to external data services and possibly fetch data from external data services. Figure 13 shows the modelling of the external data services and is the submodule of the ExternalDataServices substitution transition in Figure 2. The transition EDSProvideData models that external data services may provide data into the platform, by the platform acting as a client towards the external data service. At the current abstraction level of modelling, we do not model how the data may be provided. As discussed in the modelling of the data space service, the platform may also act as a proxy for access to external data services and the EDSDataRequest models the processing of a data request from the data space service and the sending back of a data response. The marking shows a state in which there is a data message having been sent to the data service. Provide Data (DataService, EDS_DATA)
(ExternalDataService, EDS_DATAREQ(dc)) Out
EDS 1 1`(DataService,EDS_DATA)
EDS_MSG
Process
DataRequest (DataService, EDS_DATARESP(dc))
The primary purpose of the edge integration service is to support the delivery of data from the underwater wireless sensor networks (UWSNs) into the data services of the platform. Hence, it facilitates the transfer of data from the information acquisition layer into the data and application service layer (see Figure 1). The integration point is needed since the UWSNs operate with highly specialised communication protocols intended for acoustic communication and the data will have be provided to a gateway service via, e.g., 5G, WiFI, cabling or satellite communication. Figure 14 shows the modelling of the edge integration service and is a submodule of the Edge Integration Service substitution transition in Figure 3 while Figure 15 shows the modelling of the underwater wireless sensor network and is the submodule of the UnderwaterWSN substitution transition in Figure 14. The substitution transitions EISProvideData and EISPublishData model that data from the sensor may be sent to the data service and/or published on the messaging service. The marking shows a state in which a data message from sensor 3 has arrived via the gateway and one data message from sensor 2 is in the process of being published. The ProvideData transition in Figure 15 abstractly models that the underwater wireless sensor EISProvideData
ProvEidIeSData network will send data to the gateway (represented by the GW) port place for delivery into the platform by the edge integration service.
SS In SS_MSG (SecurityService, SS_REQ ss_requests) (SecurityService, SS_Response) Receive Requests ss_requests Idle
1 Processing 1 1`() SS_AUTHOR_REQ
SS_AUTHEN_REQ Requests 2 11``SSSS__AAUUTTHHEONR__RREEQQ++ SS_REQUEST
Process Authorizaiton
Process Authentication
Completed
Marine data presents a range of challenges, including diverse formats, inconsistent quality
control methods, and varied potential uses. In a previous study, we identified that marine data
can be represented in diferent formats, and data producers are the ones who decide which
format to use, making data interoperability a significant challenge [
We have presented our initial CPN model of the smart ocean data and application platform based upon our recent work in identifying challenges and requirements for marine data services. The present model focussed on service interaction, and as a consequence we have chosen a high-level of abstraction in the modelling as our main purpose has been to make explicit the services that constitute the platform and the systems that can interact with the services. The CPN model presented in this paper is based upon a series of workshops involving consortium stakeholders from both industry and research. The aim of these workshop has been to define the components that constitute the platform and these have now been specified in the form of a CPN model. Our long-term goal is to use the CPN modelling as a conceptualisation and implementation independent specification of the platform.
The modelling approach presented in this paper has many similarities with the CPN modelling
of a fire risk notification system presented in [
We are currently prototyping the platform component and as of now we have initial
implementations of the messaging service based on the MQTT protocol and the data space service
based on REST APIs. The implementation of the data space service has also involved the
application of external data services. In terms of data providers, we have data source originating
from a test-site involving an underwater cabled sensor network and an underwater acoustic
sensor network. As we are moving forward with the implementation of the services of the
platform, we intend to evolve the CPN model alongside the implementation work based upon
the iterative methodology that was proposed [
As part of our ongoing work with implementation of the platform, we have also introduced a monitoring service aimed at providing key performance indicators in real-time on the platform itself. The key performance indicators include measures such as time delays data delivery, data format validation, and status of the services. Once the concept of the monitoring service is better understud, this will be added as a service to the CPN model. The current CPN model is primarily aimed at reflecting the platform architecture and using simulation to visualise the service interaction. As the implementation of the platform progresses, we anticipate to increase the level of detail in the modelling which may in turn allow for validation and verification of behavioral properties using model checking. This in particular applies to the data space service which is currently being further developed to include data source discovery and meta-data support which in turn in results in more complex data service interactions.
The work presented in this paper was supported by SFI Smart Ocean NFR Project 309612/F40.