576 lines
21 KiB
Markdown
576 lines
21 KiB
Markdown
file-path:: file://C:/Users/david/Zotero/storage/CBP56TTH/JSSOFTWARE-D-22-00977_reviewer.pdf
|
||
|
||
- Runtime monitoring
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 63b59e92-3ad2-42cb-94b7-c3d93d0d9235
|
||
hl-stamp:: 1672846996863
|
||
- reating probes to instrument the system, and defining constraints to be checked at runtime
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 63b59ec1-e257-4f69-b01e-07f8193a10a5
|
||
- generic monitoring platforms do not adequately cover domain-specific monitoring requirements
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 63b59ecb-f5b8-4703-8193-76afe7140b3a
|
||
- Generating CPS Runtime Monitors
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 63b59ede-98fd-4f0c-bb07-714729f53973
|
||
- esults show that GRuM facilitates the creation and evolution of a runtime monitoring platform with little effort and that the platform can handle a substantial amount of events and data.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 63b59f13-a778-48f7-ac2f-eb660328dee8
|
||
- we present GRuM(Generating CPS Runtime Monitors), a framework that combines model-driven techniques and runtime monitoring, to automatically generate a customized monitoring platform for a given SuM.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 63b59f6e-a0c7-44cb-a21e-5ad1da709790
|
||
- nmanned Aerial Vehicles (UAVs) are engaged in search-and-rescue flights in close proximity to humans, or when robots operate on a factory floor, precautionary measures need to be taken to ensure that the CPS adheres to its specified requirements and operates within its predefined safety envelope
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5a322-ec86-4fb2-b674-ed9494c1278d
|
||
- monitoring diverse properties at runtime
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5a327-e314-4079-af26-4d302f7c526a
|
||
- eterogeneity of hardware and software components within a CPS means that creating and implementing monitors, and subsequently collecting, processing, and checking the required data is often an arduous and time-consuming task.
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5a32f-9a3c-47e1-9e52-4aa47a591e4f
|
||
- source code instrumentation
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5e945-127f-4b55-9d7a-3cce21698738
|
||
- off-the-shelf monitoring approache
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5e968-b2fb-49e8-8e52-e8580b947151
|
||
- often provide inadequate support for instrumenting custom systems
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5e96e-d017-4521-b952-57c85266e0b3
|
||
- Few approaches have addressed the challenge of automatically generating customized, system-specific, runtime monitoring solutions and their maintenance and evolution support.
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b5e998-f6f6-4e35-88ae-01e73e73dd23
|
||
- When a new feature or functionality is introduced, the model is updated, and its respective code regenerated. As a result, MDE has been shown to improve productivity by enabling developers to specify a system at a higher level of abstraction
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b6dd9d-7eec-4314-9823-1fcf1c4f484a
|
||
- However, the application of MDE has fallen short of enabling the generation and evolution of a complete monitoring platform [16].
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 63b6dda5-192a-4345-9070-7ee6d73084f9
|
||
- Generating CPS Runtime Monitors
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: green
|
||
id:: 63b6ddd2-46eb-41c4-a61d-3387b2c0d3f4
|
||
- readily extended and updated when changes to the monitored system occur
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 63b6dddf-5ecb-45d7-b5b8-393724736bf6
|
||
- parts of the system that are relevant for the monitoring infrastructure
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: purple
|
||
id:: 63b6de2a-ca80-4a46-a6bc-ab999d7b0aca
|
||
- This paper builds upon our earlier work [17, 18], in which we collected requirements for model-driven monitoring and derived an initial architecture.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: yellow
|
||
id:: 63b6de38-c645-47c6-bc9a-90e54cc15ecb
|
||
- e evaluate our approach against a system for deploying UAVs for search-and-rescue and a second system that uses a set of mobile robots to assess indoor air quality.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 63b6dea8-1a08-44f5-8911-b86abc792f77
|
||
- irst, we present a monitoring metamodel that enables us to generate a custom monitoring platform with a runtime model, instead of implementing it manually
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: purple
|
||
id:: 63b6deb4-c1eb-4a3e-bc87-57c1348dcb07
|
||
- econd, probes are automatically generated for the target technology
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: purple
|
||
id:: 63b6debe-f03c-4254-a86b-06f38ac4d5eb
|
||
- e can leverage different types of (off-the-shelf) constraint engines depending on the monitoring needs,
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 63b6df15-7ea3-43af-aebb-795cf2f86360
|
||
- nce a probe generator for a specific technology has been implemented, evolving the monitoring framework alongside the SuM is greatly simplified and only requires a few steps to update the model and automatically regenerate the platform1.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 63b6df23-1605-4d30-8f03-71afeea590a0
|
||
- existing approaches are typically customized for a specific type of system, application domain, or support particular types of constraints
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: green
|
||
id:: 63b84bca-3d81-462d-8bbe-66989d750b4c
|
||
hl-stamp:: 1673022412730
|
||
- significant upfront investment is required to implement and maintain custom monitoring infrastructures, often without inbuilt support for maintenance and evolution after deploymen
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 63b84c07-ed8b-4501-bd4e-384ff614c0da
|
||
hl-stamp:: 1673022476737
|
||
- Dronology, an open-source, multi-UAV system [31] with support for planning and executing UAV missions
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: green
|
||
id:: 63b84c53-bb7f-484f-88c2-537eaf2e33b2
|
||
hl-stamp:: 1673022549702
|
||
- constraint engine needs to be configured to check constraints, such as whether the UAVs remain within their designated altitude band, avoid no-fly zones, and are flight-worthy
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 63b84c87-e7ab-40aa-967c-266d2f0124f6
|
||
hl-stamp:: 1673022602996
|
||
- if a new water sampling capability were introduced to Dronology, it would require additions and modifications to the hardware and software components
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 63b84cf3-71d7-4f10-ad68-ab7b8300fad8
|
||
- New downward-facing sensors would be required to ensure that the UAV maintains a stable distance from the water during the collection process.
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 63b84d01-b9bc-45ea-9aa3-4515958337f9
|
||
- to reduce the cost and effort of creating and maintaining a runtime monitor as illustrated for Dronology, it is necessary to (i) provide automated support for creating a system-specific solution, including the setup and configuration of the monitoring system and specification of its respective constraints, and (ii) avoid the additional effort of maintaining the monitoring system itself by enabling the infrastructure to co-evolve alongside the SuM.
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 63b84d29-556c-4ed6-b174-8d1c904de7b5
|
||
- support
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: purple
|
||
id:: 63b84d3c-6ba7-4474-b84f-b57b7b8d25dd
|
||
- runtime monitoring architecture
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: purple
|
||
id:: 63b84d40-9e02-4247-87ae-b3ef322b30c7
|
||
- ease the task of maintaining and co-evolving monitors
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: purple
|
||
id:: 63b84d44-5f07-4517-a9ac-8f92143e2f6a
|
||
- one of the novel characteristics of GRuM is that for a SuM, both a Set of Probes, as well as a fully customized Monitoring Platform can be generated based on a model describing the parts to be monitored
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: purple
|
||
id:: 63b84d5f-e656-4b1d-ac2b-e1594fb26ac1
|
||
- MDE has been used extensively to generate applications and system components across a wide variety of domains, including automotive, railroad systems, business process engineering, and embedded system
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 63b8504a-bc50-42b1-a9e5-4bd230b6cb07
|
||
hl-stamp:: 1673023566926
|
||
- It only requires the parts of the SuM that need monitoring to be modeled, instead of the entire SuM
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: purple
|
||
id:: 63b8521a-5f39-43f0-b96f-b70cac48551a
|
||
- GRuM Monitoring Setup specifies exactly what parts of the system should be monitored and provides the mechanisms for performing the monitoring.
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 63b852a7-7364-4891-8f12-2dcb7a9de705
|
||
- monitors are typically defined and developed individually for each type of system or technology, such as byte-code instrumentation or dedicated service busses in service-based systems
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: purple
|
||
id:: 63b852c6-cddb-49b5-bf32-bcc6037f341c
|
||
- GRuM leverages MDE to describe the components of the SuM that need to be monitored, and then subsequently generates the monitoring infrastructure. To support this process we have created a dedicated MMM that can be used to define the relevant parts of the system for the resulting probes and the Monitoring Platform.
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: purple
|
||
id:: 63b852eb-9e43-4bf6-bfa9-68d88785b9ff
|
||
- [:span]
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63b85327-1a50-4bce-beae-3d3166e02e8e
|
||
hl-type:: area
|
||
hl-stamp:: 1673024292567
|
||
- monitoring configuratio
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 63b85343-2435-47bd-87ef-301dfe08d591
|
||
- ach agent has its own set of monitorable properties (MoProperty)
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 63b853d1-3270-4151-af33-442d8dc3f2aa
|
||
- Weaved Monitoring Model
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63b8544c-d455-4466-bbf7-dfcbc74bc71c
|
||
- determine
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63b8545c-7686-4e60-8ef5-b3e7585ea5b1
|
||
- Fragment
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63b85462-8942-47e0-a124-c2b18e70dba7
|
||
- Domain Model Fragment. Model weaving has been used in the past to connect di
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63b85463-7db9-4ebc-992d-cb38e3e81195
|
||
- Domain
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63b8546a-5a46-4bfd-96cb-585c2e5cb51d
|
||
- Weaved Monitoring Model (WM)
|
||
ls-type:: annotation
|
||
hl-page:: 8
|
||
hl-color:: green
|
||
id:: 63bc209d-5ea9-44aa-8d25-7a9ab6c963c4
|
||
- MonitorableAgent
|
||
ls-type:: annotation
|
||
hl-page:: 9
|
||
hl-color:: green
|
||
id:: 63bc20c2-f803-4aa9-817f-6b7efdf1124c
|
||
- MonitorableProperty
|
||
ls-type:: annotation
|
||
hl-page:: 9
|
||
hl-color:: green
|
||
id:: 63bc20da-6333-4e6e-8105-ee54459adbd3
|
||
- a set of probes for collecting information from the system
|
||
ls-type:: annotation
|
||
hl-page:: 9
|
||
hl-color:: green
|
||
id:: 63bc2108-6456-410f-a2d1-c1be07754983
|
||
- an instance of the Monitoring Platform for the SuM
|
||
ls-type:: annotation
|
||
hl-page:: 9
|
||
hl-color:: green
|
||
id:: 63bc210e-3e69-402f-82a3-567964e08b39
|
||
- Listing 1: Excerpt of the WM for the Dronology system
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: red
|
||
id:: 63bc2121-6652-4fe7-b050-b8cdad6ab34d
|
||
hl-stamp:: 1673273639057
|
||
- technology and language-specific set of probes
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 63bc23b3-6bcd-4642-b9a2-6f19513b316f
|
||
- can be reused for other Java-based systems
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: yellow
|
||
id:: 63bc23da-0963-4981-ae5c-53430a12cd50
|
||
- Model Query Engine
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 63bc2806-ba39-469d-bb8f-3f38e407f847
|
||
- monitoring platform
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 63bc2832-d384-4ab8-ab4a-532998064a8d
|
||
- Domain Model Fragment
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 63bc28e1-fadf-48da-86b8-ca5657cc5886
|
||
- monitoring concepts
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 63bc28ec-84f8-492c-a609-61078e074c0a
|
||
- . Platform and Probe Generation
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: green
|
||
id:: 63bc2905-d93e-4942-8736-3ac187f3af8d
|
||
- Platform Usage & Runtime Monitoring
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: green
|
||
id:: 63bc290b-1633-4f88-b90b-fea5bdea3f31
|
||
- integrated directly by the developers, or as part of the continuous integration process
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: green
|
||
id:: 63bc295d-550f-4de2-b1cb-73509e58fa22
|
||
- MoProperties
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: green
|
||
id:: 63bc2975-3d85-4834-88ce-664f9e25dad5
|
||
- middleware
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: red
|
||
id:: 63bc29c7-2d78-45e7-b64b-6960153edc1b
|
||
hl-stamp:: 1673275851592
|
||
- System Evolution
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: green
|
||
id:: 63bc2c03-c483-48ce-9129-94f69843e64d
|
||
- easily incorporated into the monitoring platform as well
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: yellow
|
||
id:: 63bc2c1a-34b8-4d0b-be34-e1cbb7837ab6
|
||
- if an additional property of an existing agent needs to be added to the set of monitored properties, this change can be directly performed at the model level
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: green
|
||
id:: 63bc2c88-d71f-4f10-b24a-a1f90473d7f0
|
||
hl-stamp:: 1673276556244
|
||
- probes and platform code can be completely regenerated without the need to manually adapt the code.
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: green
|
||
id:: 63bc2c96-14c6-4b29-b36d-ecb07f300a72
|
||
- we used XText [48] to define a textual domain-specific language (DSL) for the WM (see example in Listing 1) which allows easy creation and modification of the WM for a specific SuM.
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: green
|
||
id:: 63bc2cc9-913c-4875-ba32-16a44e4ca432
|
||
- two distinct code generators to support two different target languages and technologies
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: green
|
||
id:: 63bc2cf1-9729-4c1a-b1f4-935e9a74f5b9
|
||
- At runtime, an instance of the Domain Model Fragment is created and used as the runtime mod
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: green
|
||
id:: 63bc34c6-ecf6-4257-949c-8cc6368eedbd
|
||
- while Viatra provides tools and incremental evaluation [50, 51], it does not support more complex constraints, such as temporal ones
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: green
|
||
id:: 63bc34ef-60cb-4d02-9f1d-5c650e421622
|
||
- Complex Event Processing (CEP)
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: green
|
||
id:: 63bc34f6-af00-4441-b614-31c647f4bfae
|
||
- reasonable effort
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: green
|
||
id:: 63bc350a-20f4-4023-b84c-a21d3d59637f
|
||
- ssessing the effort
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: green
|
||
id:: 63bc3520-d8e4-428d-94ad-1d061aca2075
|
||
- create a runtime monitoring platform
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: green
|
||
id:: 63bc353c-0697-49fe-b5b0-7201729e3258
|
||
- efficiently monitor timesensitive runtime data
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: green
|
||
id:: 63bc3554-ca84-4bd0-aafa-bccd035bf95d
|
||
- measuring the model-set-latency of the monitoring platform
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: green
|
||
id:: 63bc355c-1fe9-4c95-b898-c3da06873b95
|
||
- [:span]
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: green
|
||
id:: 63bc35c8-e461-49f2-bb21-0894eb707c50
|
||
hl-type:: area
|
||
hl-stamp:: 1673278967744
|
||
- [:span]
|
||
ls-type:: annotation
|
||
hl-page:: 15
|
||
hl-color:: blue
|
||
id:: 63bc35db-b13e-4b50-8786-1b1247c510ae
|
||
hl-type:: area
|
||
hl-stamp:: 1673278963252
|
||
- One was assigned to Dronology and one to the TurtleBot system. We then recorded the time taken to complete each activity
|
||
ls-type:: annotation
|
||
hl-page:: 16
|
||
hl-color:: green
|
||
id:: 63bc3625-fdfd-41bb-8927-1eb4ae8a2a23
|
||
- “thinking-time” which is expected to be similar whether the monitor is built from scratch or using GRuM
|
||
ls-type:: annotation
|
||
hl-page:: 16
|
||
hl-color:: green
|
||
id:: 63bc36b3-4eda-4775-b6be-0c8f7c49ad99
|
||
- Case 1 – Dronology
|
||
ls-type:: annotation
|
||
hl-page:: 16
|
||
hl-color:: yellow
|
||
id:: 63bc36d5-0483-4755-a056-2791ccff2036
|
||
- . Altogether, the implementation of constraints and extensions was completed within about 20 hours
|
||
ls-type:: annotation
|
||
hl-page:: 16
|
||
hl-color:: green
|
||
id:: 63bc373d-6509-4c88-b90f-92461a5feab0
|
||
- Case 2 – ROS TurtleBot
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: yellow
|
||
id:: 63bc8375-d23b-4bbc-9243-2d09308bbaf7
|
||
- MQTT-Forwarder for sending data to the monitoring platform
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 63bc8640-7bfa-4af3-907b-46e1ac2035c9
|
||
- we developed this application from scratch without prior experience with the system or technolog
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 63bc8656-7c76-4036-95f7-b7ce1c5b9db4
|
||
- Domain Model Fragment (1) for the TurtleBot consisted of 10 properties with 23 attributes
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 63bc8664-4d45-4a74-8799-cb3b5ffcda16
|
||
- 5 hours were spent implementing the GRuM monitor after properties had been selected.
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 63bc8676-efb4-451c-9da0-1b829fa35207
|
||
- 7 constraints
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: yellow
|
||
id:: 63bc8686-dc99-41a6-82de-3a2ce739f55c
|
||
hl-stamp:: 1673299592488
|
||
- add monitorable properties to a system, perform constraint checks using the newly collected data, update an existing element (e.g., change the information and/or type of a property) and remove an existing element from the model.
|
||
ls-type:: annotation
|
||
hl-page:: 18
|
||
hl-color:: green
|
||
id:: 63bc86cb-beb5-48e0-994c-f4f7cf397cff
|
||
- (i) a new property
|
||
ls-type:: annotation
|
||
hl-page:: 18
|
||
hl-color:: green
|
||
id:: 63bc871e-d222-4e37-b7ad-e572d117e3ce
|
||
- (ii) an existing property is modified
|
||
ls-type:: annotation
|
||
hl-page:: 18
|
||
hl-color:: green
|
||
id:: 63bc8722-c6fd-439a-a364-7f2ed534e90e
|
||
- (iii) a property is removed
|
||
ls-type:: annotation
|
||
hl-page:: 19
|
||
hl-color:: green
|
||
id:: 63bc8729-ad90-49ff-85c2-13e801b16ecd
|
||
- GRuM provides a high degree of automation, reducing the manual effort that is required to adopt changes in the SuM in the monitoring platform
|
||
ls-type:: annotation
|
||
hl-page:: 20
|
||
hl-color:: green
|
||
id:: 63bc8844-2328-4e0e-a762-242a28dabef1
|
||
- UAV search mission scenario
|
||
ls-type:: annotation
|
||
hl-page:: 20
|
||
hl-color:: green
|
||
id:: 63bc88ce-0356-485a-b835-9fb0758039e8
|
||
- multiple UAVs search for a missing person in a predefined are
|
||
ls-type:: annotation
|
||
hl-page:: 20
|
||
hl-color:: green
|
||
id:: 63bc88d3-7c15-48e1-b7a2-577a904f39dd
|
||
- he monitoring infrastructure was set up on a standard Desktop Computer, with 16GB of RAM, running Ubuntu 20, using Java 11, and Ecore2.23. We randomly assigned 5 flight routes to each UAV, and then collected runtime data and performed constraint checks
|
||
ls-type:: annotation
|
||
hl-page:: 20
|
||
hl-color:: green
|
||
id:: 63bc8a4b-25b3-4de5-8282-ec5ba0a98ec1
|
||
- violations were reported correctly
|
||
ls-type:: annotation
|
||
hl-page:: 20
|
||
hl-color:: yellow
|
||
id:: 63bc8a59-5a7e-42df-9bfb-8d4907972f2a
|
||
hl-stamp:: 1673300571717
|
||
- 8 Speed Reduction: When the bot operates below 25% battery level, the speed must not exceed 2.0m/s anymore
|
||
ls-type:: annotation
|
||
hl-page:: 21
|
||
hl-color:: yellow
|
||
id:: 63bc8ab5-04aa-41e8-874a-2daabadc35cb
|
||
- Measurements Accuracy: To ensure accurate measurements, an alert should be raised when measurements are transmitted while movin
|
||
ls-type:: annotation
|
||
hl-page:: 21
|
||
hl-color:: yellow
|
||
id:: 63bc8abf-1f59-4501-b889-c24a41460417
|
||
- temporal constraints with Esper
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: yellow
|
||
id:: 63bd3b61-ad54-4cd7-ac3b-dc9e9e023335
|
||
- properties
|
||
ls-type:: annotation
|
||
hl-page:: 19
|
||
hl-color:: red
|
||
id:: 63bd3dac-e5ae-49f4-85e9-8f01bca6086b
|
||
hl-stamp:: 1673346492075
|
||
- While these were created by several authors of this paper
|
||
ls-type:: annotation
|
||
hl-page:: 25
|
||
hl-color:: red
|
||
id:: 63bd3e0b-459b-451d-b8b6-9cf6a59f5ccb
|
||
- differences in terms of the technology used, their architectural styles, and propertie
|
||
ls-type:: annotation
|
||
hl-page:: 25
|
||
hl-color:: red
|
||
id:: 63bd3e3b-ce26-459a-be0d-55e85b21618c
|
||
- While we have been using a simulator for the Dronology use case, Ardupilot is a high-fidelity simulator providing a realistic execution environment, and our previous experience has confirmed that this closely resembles real-world scenarios
|
||
ls-type:: annotation
|
||
hl-page:: 25
|
||
hl-color:: green
|
||
id:: 63bd3eaf-efaf-4f43-8f73-1d18b7c7e705
|
||
hl-stamp:: 1673346742690
|
||
- (1) describe relevant properties
|
||
ls-type:: annotation
|
||
hl-page:: 26
|
||
hl-color:: green
|
||
id:: 63bd3ee0-946a-4865-b841-e943c61cdb66
|
||
- (2) collect and check runtime data via the automatically generated monitoring platform
|
||
ls-type:: annotation
|
||
hl-page:: 26
|
||
hl-color:: green
|
||
id:: 63bd3ee6-1d8a-4d48-99ca-d62b084570eb
|
||
- automatically generating runtime monitors
|
||
ls-type:: annotation
|
||
hl-page:: 28
|
||
hl-color:: green
|
||
id:: 63bd3f87-6ff3-4b79-b468-02c18c85df1b
|
||
- SuM’s technology and architectural style
|
||
ls-type:: annotation
|
||
hl-page:: 28
|
||
hl-color:: yellow
|
||
id:: 63bd3f97-8395-4b79-b765-50f7e9ffe7fb |