SE4SG 2013 Presentation by Selim Ciraci at 2nd International Workshop on Software Engineering Challenges for the Smart Grid. Please cite our workshop as Ian Gorton, Yan Liu, Heiko Koziolek, Anne Koziolek, and Mazeiar Salehie. 2013. 2nd international workshop on software engineering challenges for the smart grid (SE4SG 2013). In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13). IEEE Press, Piscataway, NJ, USA, 1553-1554.

1. A Run-Time Verification Framework for Smart Grid
Applications Implemented on Simulation
Frameworks
Selim Ciraci (PNNL)
Hasan Sozer (Ozyegin University)
Bedir Tekinerdogan (Bilkent University)

2. Outline
Motivation
Simulation of Smart grid Applications
Behavioral Constraints
Example: Market Bid Application
ConArch Framework
Modeling Behavioral Specifications
Generation of runtime verification automata
Mapping Software Architecture to Implementation
Runtime observers and verification
Application of ConArch to Market Bid Application
Conclusions and future work

3. Simulation of Smart Grid Applications
Smart gird combination of electrical grid with communication
networks.
Sensors gather information (e.g., supply/demand information).
This information is carried to control centers with communication
networks.
Before deploying an application for the smart grid, it is important to
analyze:
How network delays/errors effect the application
Whether the control logic of the application is correct

4. Simulation of Smart Grid Applications
Usually developers/ designers do not
have access to large power grid and
communication network to be used as a
test-bed.
Simulation systems are utilized to analyze
the new smart grid applications.

5. Behavioral Constraints and Smart Grid
Applications
Electrical grid is a mission critical infrastructure.
Smart grid applications are subject to behavioral constraints.
Most of these constraints are systematic
Defined at the architecture deign level as sequences of interactions between
components/connectors.
To verify behavioral constraints:
Software architecture should be evaluated
Implementation should be tested

6. Behavioral Constraints and Smart Grid
Applications
• Testing of Smart Grid applications is realized with simulators.
• How can we be sure that the implementation follows the
behavioral constraints?
If implementation is incorrect, simulation results can be
misleading.
Implementation deviates from the planned architecture.
Harder to find interactions in the source code.

7. Example: Market Bid Application
Used for calculating the cleared
price of electricity.
Controllers attached to the air
conditioning units (AirCo).
Before turning on, AirCo notifies
the Controller.
Controller bids a price for
electricity with the power
demand from the AirCo.
AuctionHouse collects the bids
from controllers. Then, sends a
response message stating the
price of electricity of the next
interval.
Depending on the price
Controller arranges the settings
of the AirCo.
This is a behavioral constraint of the
Market Bid Application. How can we
verify this constraint for implementations
with a simulator?
With a simulator, the implementation
deviates from planned architecture.
Interaction BidRps() is implemented in
method ControllerInterface.commit()

8. ConArch - An Approach for Detecting
Inconsistencies between Behavioral
Models of the Software Architecture and
the Code
Utilizes architectural behavioral constraints for runtime verification.
Converts behavioral constraints to formal specifications.
Generates runtime monitors, that observe and record the execution of
the software system.
Online verification: runtime verifier evaluates whether the observed
execution follows the behavioral constraint.

9. ConArch and verification of Smart Grid
Applications
ConArch provides programmable architecture to source code
mappings.
Does not make assumptions, such as interaction A() is implemented as a
method A(), about how the architecture is implemented.
Users implement queries on the abstract-syntax tree (AST) to specify the
methods, classes, and conditions that map to the architecture.
Programmable mappings provide flexibility:
Mapping can still be accomplished even though the implementation
deviates from the planned architecture.
Allows verification for implementations for smart grid applications
implemented with simulator frameworks.

10. Modeling Behavioral Constraints in ConArch
UML sequence diagrams are
used for modeling behavioral
constraints.
Interactions can be
asynchronous, synchronous.
Conditional, optional frames can
be used model the control flow.

11. Generation Formal Specification
ConArch converts UML sequence diagrams to formal
specifications as Finite State Machines.
FSM explicitly shows each possible path of the control flow.
Asynchronous interaction
Bid(), Controller initiates the
interactions then executes the
return interaction bidSent() -> two
paths in control flow

12. Mapping interactions to the implementation
Prolog is utilized for querying the
AST.
ConArch provides tools for
converting C++ and Java to
Prolog facts.
Users implement queries
(Prolog rules) over these facts.
Facts representing
Java AST.
Prolog Query for that maps
initiation of interaction
Controller.Bid() to the call
ControllerInterface::Bid() where
ControllerInterface::
inboxCounter >0
Commit is a method required
by the simulator
framework, developers had
to use this method to
implement an interaction.

13. Mapping interactions to the implementation
ConArch provides a repository of Prolog rules for mapping
interactions to implementations.
With these rules common styles for implementing interactions with
simulators can be mapped in a much easier way.
E.g.: mapEventHandler(), mapTickHandler(), mapEventScheduling(), …
Commit() is a tick handler method, instead of the query shown in previous
slide we could use the rule mapTickHandler() from the repository.

14. Runtime Observers and Verification
Runtime monitors are aspects that intercept the
execution when the control reaches a
call/method that corresponds to an interaction.
Intercept
ControllerInterface::
commit()
Send to runtime verifier
that the method
corresponding to
interaction is
Controller.Bid() is
executed.

15. Runtime Observers and Verification
Runtime verifier receives the information about executing interactions
from the monitors.
It traces the FSM with these interactions and tests whether the FSM
yields to an accept state.
Current State
of runtime verifier
Incoming message from monitor:
executes Controller.Bid()
New state of
runtime verifier

16. Application of ConArch to Market Bid Application
We used ConArch to verify the Market Bid Application implemented
with GridLAB-D and ns-3 simulators.
9 classes in total.
C++ to Prolog conversion completed 6mins. Mapping of 10
interactions completed 15seconds.
10 aspects are generated.
11seconds runtime overhead.
Verification captured one violation of the behavioral constraint:
Controllers were executing a Bid() interaction instead of a
adjustThermostat () interaction.
Caused due to improper handling of delays messages from the network.
Problem confirmed by developers!

17. Conclusions and Future work
Flexible mapping is needed because the implementation can deviate
from the planed architecture.
For applications implemented with simulator frameworks deviation is
unavoidable.
ConArch can be utilized for verification of smart grid applications
implemented with simulation frameworks.
Future work:
We plan to extend the repository for common mapping.
Integrate ConArch to deployment phase, so it can be used when
applications are deployed.
Allows developers to capture misbehaving applications.