Architecture
The SFINA framework is outlined in three layers:
The three main layers of the SFINA framework.
Regulation models, policies and mechanisms are generic and reusable implementations by the users of the SFINA software.
Flow networks are an abstraction of domain knowledge and dynamics.
Domain knowledge and dynamics concern real-world data and physical laws that govern techno-socio-economics systems.
The three layers of the SFINA framework are realized with the following architecture of 7 components:
Protopeer is a distributed prototyping toolkit that provides networking, scheduling, logging and deployment services to the overall
The flow analyzer computes the distribution of the flow in the network according to the selected domain backend.SFINA framework.
The flow network contains and manages information about the nodes, the links and their topology.
The simulation agent orchestrates all other components by scheduling operations and executing simulation events.
The file system loads all required information for the simulation. Input data can be reloaded during simulation and output data are written to files during simulation for further post analysis.
The backend agent is responsible for the power flow analysis given the structural and functional dynamics of a flow network.
The applications expand the functionality of the simulation agent and implement policies, models and mechanisms for the flow regulation.
An outline of the SFINA framework.
The execution of a simulation consists of the following run time periods: (i) system, (ii) bootstrapping, (iii) simulation, (iv) step and (v) iteration.
The system run time is the total execution period of the SFINA simulation software. It is measured with a Protopeer clock in simulation or live deployment mode. System run time consists of the bootstrapping run time and simulation run time.
During bootstrapping, the simulation is initialized by loading the required input information for the simulation. The duration of the bootstrapping period is chosen by the user. Simulation run time is equal to the system run time minus the bootstrapping run time.
It consists of discrete simulation steps of equal length during which measurements are logged, events are executed and flow analysis is performed. The main operations of applications are also executed in each of the simulations steps.
Time management in SFINA.
Finally, each simulation step optionally defines a number of iterations that model sequences of evolving events. For example, the failure of a power line in a power network may result in a cascading failure during which several other lines consecutively fail.
The evolution of a cascading failure can be modeled and studied with the iterations of SFINA. An event in SFINA is the adjustment of flow, topology or system parameters during simulation run time.
An event can be static or dynamic. Static events are encoded oine and manually by the user. They are loaded in the simulation by the file system. Dynamic events are created in an automated fashion during simulation by the application logic.
A SFINA application can run single-threaded or multi-threaded in a single machine. It can also run in a cluster or even be deployed in a real-world operational system such as Planetlab4 or cloud computing infrastructures.
Protopeer supports these deployments options. Distributed simulation scenarios may include computationally intensive simulations, modeling of inter-dependent flow networks or even multi-domain simulations. SFINA can also run as a web service so that it can be used in the future within architecture-driven, service-oriented and workflow-based development environments, e.g. BEPEL representation from workflow to executable.
The Protopeer toolkit
An outline of the Protopeer architecture. SFINA inherits all services and prototyped functionality of Protopeer and therefore it can be deployed and run as a fully decentralized networked system.
SFINA is prototyped as a distributed system by design using the interfaces of the Protopeer library. The simulation and backend agent extends the functionality of the ‘peerlet component’. Therefore, all SFINA applications written on top of the core simulation agent have a network API with which they can exchange messages in real-world networking environments.
Moreover, SFINA applications and domain backends have access to measurement and logging services that can be used for a postanalysis of the simulation results. The core simulation agent inherits the scheduling functionality of Protopeer that reduces low-level programmatic e ffort required by developers of applications.
In summary, low level complexity such as scheduling, networking, logging and measurements is hidden from developers of the SFINA applications that can focus entirely on the development of flow regulation functionality. Although the current SFINA implementation is supported by Protopeer library, the design of SFINA does not depend on Protopeer. SFINA interfaces allow the replacement of Protopeer by another system if this becomes a requirement in the future.
File system
SFINA relies on a structured file system for:
Four file types are loaded in system run time with the following information:
Flow
It contains domain-dependent information about the physical characteristics of the network that govern how flow is distributed. For example, for a power system this file may contain the values of line impedance, node voltages, etc. For traffic systems it may contain physical characteristics of vehicles, traffic lights or road intersections.
Events
It encodes changes of information about a node, link or system parameter at a certain simulation step. For example the removal of a line at a certain step can be encoded by a static event.
Parameters
It contains global system-wide parameters of the simulation such as which domain backend is selected for the simulation.
Network
It contains domain-independent information about the topology, meaning which nodes the links connect.
Flow and network file types can be reloaded and exported at any simulation step, in contrast to the events and parameters that are loaded only once at the initialization phase. At this development stage, the SFINA file format concerns comma-separated text files for easier use and readability of the data used in the simulation. SFINA contains extensible utilities that convert back and forth other file formats6 to SFINA format so that the user can use state-of-the-art datasets generated from various domain backends. The data loaders of the file system are modular and can be extended to parse future data types required in simulations.
Interactive topology formation. Insertion of flow information. Insertion of flow values.
Auto-generation of input files based on user-friendly input to a graphical user interface.
The input files can be interactively generated and modified via a GUI. Instead of generating the flow network information programmatically, the files can be auto-generated from userfriendly input given via the SFINA GUI.
Flow analyzer
Flow analysis is the calculation of the flow in the links and nodes of the flow network given the physical characteristics of the studied domain and perturbations introduced by the executed events.
A flow analysis highly depends on the domain-specific physical characteristics of the studied network and the physical laws that govern such a network.
Flow analysis is performed at each simulation step. It can actually be executed several times following the execution of static or dynamic events.
The output of a flow analysis can be used to tailor decision-making and future regulatory actions on the flow network.
The backend agent
During bootstrapping, the backend agent loads and parses the flow information from the file system.
It provides, through the simulation agent, a generic interface for flow analysis that is agnostic of the actual implementation of the adopted domain backend.
It is the backend agent that makes the acquired instantiation of the flow analysis based on the selected domain backend adopted in the simulation.
In this way, the application developer does not need to implement flow analysis algorithms but can use several existing ones implemented at di fferent domain backends.
Flow network
A flow network in SFINA consists of a set of uniquely identified nodes and directed links that contain the flow information loaded from the input files. A node contains a set of incoming and outgoing links. Respectively, a link contains a starting node and ending node. A network is connected if there is a path between any of the nodes, otherwise the network is disconnected to graph components referred to as islands.
The flow network manages the topology. Nodes and links have two statuses: (i) activated/deactivated and (ii) connected/disconnected. The former status mandates whether a node or link is operational during the simulation. Events may determine this status. The latter status denotes whether a node or link is adjacent to a link or node respectively that actually determines the topology of the flow network.
Nodes and links have a (i) flow and (ii) capacity. The information type of flow and capacity is determined by a system parameter and should be information contained in the nodes and links. The flow type represents a resource distributed in the network and studied in the performed simulation. The capacity type determines which quantity can make a node or link overloaded that may result in activation/deactivation and, therefore, connection/disconnection from the topology.
The management of the topology is hidden from applications. This means that a generic interface allows adding/removing nodes and links. The update of the graph occurs in the background without programmatic e ort by developers. A flow network contains general-purpose topological and graph spectra metrics such as the node degree, closeness centrality, degree centrality, degree distribution, clustering coecient, shortest path and other. Some of this metrics are calculated with the support of the JGrapht library. Metrics are logged in the background and are available to the researcher for post analysis. Moreover, the flow network provides the opportunity of a real-time visualization of the temporal flow network by integrating tools such as Gephi.
The Simulation Agent
The simulation agent orchestrates all other components of SFINA during system run time.
It is responsible for the execution of all scheduled events and the calculation of the network status that is the topology and the distributed flow.
For each measurement type, simulation step, node and link, registered measurements by the framework or by applications are computed, stored and logged.
At the end of each simulation step, the flow and network information are exported by the file system in the respective SFINA file format.
The above agent tasks form the active state of the simulation agent and it is executed periodically at every simulation step. During bootstrapping, the simulation agent loads the topological information from the file system and creates the static events. A call for a flow analysis by an application is routed to the backend agent for execution. A simulation agent also has a passive state that listens for external events received during simulation by other agents that may participate in the simulation.
Applications
A SFINA application is either a usage scenario of the simulation agent or an extension of the simulation agent with additional prototyped functionality.
A usage scenario of the simulation agent
In this case, minimal or no development e ffort is required.
A SFINA user undertakes the following actions:
An extension of the simulation agent with additional prototyped functionality
In this case, development eff ort is put into extending or overriding the inherited functionality of a simulation agent. This may include one or more of the following actions:
The design approach and interfaces of SFINA support the first two actions. The possibility of the third action occurring should be minimized by either adopting more e ffective software engineering practices at the application-level or updating the core simulation framework of SFINA to support more complex and tailored functionality.
Upgrading the SFINA framework to support a new domain backend requires the following actions:
Moreover, an application logic can be split into multiple communicating agents by using the generic interfaces and modular approach of SFINA.