Data Dimension for Evaluation

1. Management Information SystemsPart 6: Monitoring – Extension of Data ModelProf. Dr.-Ing. Raimar J. SchererInstitute of Construction InformaticsDresden, 14.01.2013

2. Data Dimension for Evaluation System state System design values constrains Req. values Monitoring n Campaign 1 . MC : P1Q 2 . MC 3 . MC 4 . System Investigation 1.1 S I : Selected (sub) system Retrieve design values Retrieve monit. Values 1.2 1.3 Status of our model Data Dimension for Evaluation Evaluation Keval 1.11 EV :{ΔP,ΔQ} {Qloss, Kact} 1.12 EV 1.13 EV deduced Updated System {Qloss , Kact} 2

3. Extension of Data Model INTEGER STRING INTEGER • Manage System States by an object System_State SS and • Measurement-Case by an object Measure-Case MC Measure-Case MC SS-No System_State SS-Name Max No Meas. For simplification only one system investigation cases is considered and hence Implicit part of the evaluation case, named here system_state .

4. 2. For a system state the two quantities which can show deviations of their values compared to the planned system are water loss( Qloss) located to a node and modelled as an attribute roughness in a pipe located to a pipe and modelled as an attribute both new attributes are managed by a new object “updated values” and are referenced to object Monitored_state as well as to object Node and object Pipe, respectively Extension of Data Model

5. Bare System Data Model Bare System Model contains only the system objects but no load and no behaviour information Remark: Q loss is not constant value, but slowly de-pendent on the pressure

6. System data model with sensor extention Further sensor specification can be useful for various purposes.However, they are not needed in our particular case

7. Kernel of bare system data model Changing Values Required Values Changing Values

8. Principal definition of a load case Ordered lists, i.e. element l1  r1 An additional WHERE rule can constrain this relation to be only valid for instancesof Inner_Node and Output_Node but notof Input_Node. Such rules are formallydefined in the EXPRESS language. In EXPRESS-G this is merely markedby an asterisk ‘*’,like a footnote

9. System model with added state-dependent values Evaluation Case Behaviour Values Reaction Values System Load Case

10. Modelling a design state

11. Managing design states (Load case) • A system state can be: • Design state • Investigation state

12. Modelling a design state   Additional rules can ensure that there is exactly one result object for each node and each pipe

13. Modelling a monitored state Evaluation Cases Additional free object Compared to design state Investigation State

14. Modelling a monitored state Evaluation Cases Mes P Investigation State

15. Modelling a monitored state   Additional rules can ensure that (a) measured and calculated results are disjunct, and (b) the number of all elements in both sets equals the total number of joints and pipes.    There can be L eval. cases for each monitored state, and each may contain MQloss and NK_act values  Additional rules can ensure that node_ref and Qloss,and pipe_ref and k_actare parallel lists of equal length

16. Generalisation of system states

17. Final system model

18. Deriving a new absolut system state (=8.Decision)  From the full set of evaluation cases and respectively evaluated system parameters …  decide about new system values and create new absolut system state

19. Extension of relational data base EXERCISE