ProcessType Change Requests | OGC

S e n s o r M o d e l L a n g u a g e O G C 0 7 - 0 0 0 SensorML Conceptual Models In SensorML, all components are modeled as processes. This includes components normally viewed as hardware, including transducers, actuators, and processors which are viewed as process components and sensors and platforms which are modeled as systems. All components are modeled as processes that take input, and which through the application of an algorithm defined by a method and parameter values, generate output. All such components can therefore participate in process chains. Process chains are themselves processes with inputs, outputs, and parameters. Hence, SensorML can be viewed as a specialized process description language with an emphasis on application to sensor data. Process descriptions in SensorML are agnostic of the development environment in which they might be executed, or the protocol by which data is transported between process execution modules. SensorML does not try to replace other existing technologies such as BPEL or MATLAB Simulink. It is also conceived that SensorML-defined processes could be imported and executed within other execution environments, such as BPEL or MATLAB Simulink, as well as within SenosrML- enabled process execution software. The models for SensorML and SWE Common are presented using Unified Model Language UML static structure diagrams. These UML diagrams represent conceptual models only and are not intended for automatic encoding within XML Schema. SensorML models sensor systems as a collection of physical and non-physical processes. It also supports the description of processes that have been applied to an observation i.e. observation lineage or can be applied on an observation i.e. on-demand processing. In this sense, processes in SensorML are intended as serializations of executable components. An instance of a process in SensorML should describe the inputs and outputs expected, as well as the parameters and methodology required to create output values from input values. Process models and chains are expected to be linkable, and these links are expected to be described within a process chain or system. Issue Name: Use of term “Operation” instead of “Process”. aw, 2006-12-07] Issue Description: It has been recognized that the term “Process” used in SensorML may be equivalent or similar to the use of the term “Operation” defined in ISO TC211. The issue is whether the term “Process” should be replaced with the term “Operation” within SensorML. Resolution: This will be given serious consideration as SensorML moves toward more complete harmonization with ISO standards in future versions.

8.8 ProcessType

All processes in SensorML are derived from AbstractProcess which is itself derived from AbstractFeature. All features have as a minimum, name and description properties. In addition, all processes include inputs, outputs, and parameters. These three properties Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 54 S e n s o r M o d e l L a n g u a g e O G C 0 7 - 0 0 0 take values of AnyData type Fig. 9.1. The use of these SWE common data types throughout the SWE framework of encodings and services, supports linking between SWE components as well as providing a high degree of consistency. The properties inputs and outputs represent “ports” where outside processes exchange data with this process. However, in SensorML, any parameter elements that do not have the property fixed equal to true, can also be considered as a potential input into the process. In other words, the value of any variable parameter within a process can be set or affected by outside processes or data sources. In addition to inputs, outputs, and parameters, all processes in SensorML can provide additional information that, for the sake of clarity, have been collected within a metadataGroup Section 9.4. These data, while important for resource discovery, for qualification of results, and for assistance to humans, are not considered essential to the execution of the process within a process chain. All data or information required for actual execution of the process should be included within the inputs, outputs, and parameters properties. It is possible, and encouraged that those parameters desired for resource discovery be linked to or copied within the appropriate metadata section. Figure 9.1. Conceptual model for Processes As will be discussed in the following sections, all composite processes, including ProcessChain and System, realize the CompositePropertiesGroup, which includes the process and connection properties. These allow a description of the individual processes within the process collection and the links between them. Furthermore, processes that are Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved. 55 S e n s o r M o d e l L a n g u a g e O G C 0 7 - 0 0 0 physical in nature, can include additional properties providing location information and physical interface description, as provided by realizing the PhysicalPropertiesGroup. These properties include spatialReferenceFrame, temporalReferenceFrame, boundedBy, position, and interface. Figure 9.2 provides an alternative view of processes clearing delineating between physical and non-physical processes, and atomic and composite processes. Figure 9.2. Alternative model view for physical and non-physical processes.

8.9 Non-physical or pure processes