D2.1 Requirements and Specification - CORBYS

Recommendations

Info

D2.1 Requirements and Specification Requirement No.: DMO5 Name: Device state integration with Device State Integrator (DSI) Description: Device ontology to assist device state integration Reason / Comments: Indicative priority Mandatory 7.3.2 Assumptions and Dependencies � Modelling the device ontology depends on input from partners regarding selected sensors and actuators, other devices to be used in CORBYS 7.4 SelfAwareness Realisation (Task 4.2, UR) Self-Awareness supported by Situation Assessment is an essential part of a cognitive system. It allows the system to interact with the environment in the most efficient and sensible way without the interference of an external guide. The CORBYS Situation Assessment Architecture facilitates (i) awareness of available sensors and actuators (via the device ontology) and (ii) awareness about the relationship of these devices to the environment including humans. CORBYS Situation Assessment Architecture includes a number of modules such as semantic integrators for person, device/object/entity, ontological layer for devices, domain specific (Plug and Play) ontologies and a blackboard structure acting as a globally accessible facility for situation assessment. A Device State Integrator (DSI) acts as the interface or interpreter between the sensors/actuators and the core system, using the information in the device ontology. DSI fuses all the information and makes it available to the core-architecture for further processing via the blackboard. Awareness about the relationship to the environment entails positioning, interaction possibilities with the environment, potential workflows, process flows, process maps, etc. This information is provided by an Object State Integrator (OSI) which analyses the received input information from sensor data and creates a cognitive image of the environment. A Person State Integrator (PSI) allows for the representation of the interacting person, including information such as position of the person, profile integration etc. The integrated Situation-Awareness Blackboard (SAWBB) in CORBYS allows access to designated deviceagents for relevant updates of profiling knowledge as well as the person’s current states, events, and behaviours detected by all the sensor and reasoning sub-systems. It serves to facilitate symbolic knowledge integration and inferencing at the higher semantic fusion, and enables appropriate dynamic data/knowledge sharing regarding the semantic parametric values of the situated operational context. SAWBB is a layered architecture supporting the sharing and integration of data at various levels of abstraction including raw data from sensors etc; the upper layer being in the form of an event handler/look up table and the second layer taking the form of a database to store historic and profiling information. SAWBB is a part of the high level Cognitive CORBYS control architecture; the connection of the Situation Assessment Architecture with the module responsible for perceiving, focusing, cognition, learning and responding to environment. An important part of this module is the internal representation of the robot internal self-model and self-state awareness which allow the system to reason and act based on its status, the context of assigned task and event anticipation. Two types of memory will be realised, i.e. one representing the current state of 64
D2.1 Requirements and Specification task execution (M1) and the second being the representation of the world model (M2). The Situation Assessment Architecture enables the sharing of raw sensor data from the Blackboard to support low level sensor data fusion amongst reasoning sub-systems; particularly to serve those modules within the Data Analysis Abstraction and Fusion Layer with variously designated Anticipation, Empowerment, Classification, Recognition responsibilities. Accordingly, the blackboard can receive data from any sensor configurations on the system e.g. the body area networks in the first demonstrator as well as from the mobile robotic system for examining hazardous areas. The output is the data and knowledge that can be made available at various levels of semantic abstraction for access as demanded by the agents. 7.4.1 Functional Requirements 7.4.1.1 Processes Inputs Requirement No. SAWR1 Name: Sensor input to Situation Awareness Blackboard (SAWBB) Description: From various sensing and data captures device-agents within the system e.g. Person State Integrator etc. Reason / Comments: Indicative priority Mandatory Requirement No. SAWR2 Name: Semantic input to Situation Awareness Blackboard (SAWBB) Description: For example, periodic profiling data refresh of the Situation-Awareness Blackboard (SABB) with semantically resolved structured profiling knowledge to re-update the operational profiling reference values of the Situation-Awareness Blackboard (SABB) for use by all relevant sub-systems. Reason / Comments: Indicative priority Mandatory Requirement No. SAWR3 Name: Event handling request to Situation Awareness Blackboard (SAWBB) Description: Requests that flag to indicate that a module should take action (event-handling) Reason / Comments: Indicative priority Mandatory Requirement No. SAWR4 Name: Sensor input to Person State Integrator (PSI) Description: Sensors and devices detecting and tracking person states, to provide input to the PSI so that an integrated structured state descriptor of the person at any given time, is sent to the SAWBB Reason / Comments: Indicative priority Mandatory Requirement No. SAWR5 Name: Sensor input to Device State Integrator (DSI) Description: Device inputs i.e. from sensors/actuators. All input is asserted onto the SAWBB. Reason / Comments: Indicative priority Mandatory Requirement No. SAWR6 Name: Sensor input to Object State Integrator (OSI) Description: Sensor Input are used to create a cognitive image of the environment, including relationship of an object to the environment, positioning, interaction possibilities with the environment, 65
Page 1 and 2:
CORBYS Cognitive Control Framework
Page 3 and 4:
D2.1 Requirements and Specification
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24: D2.1 Requirements and Specification
Page 73: D2.1 Requirements and Specification
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209:
show all

D2.1 Requirements and Specification - CORBYS

Create successful ePaper yourself

Delete template?

Save as template?