 This is a short introductory presentation on REAPS, a Resient Information Architecture Platform for SmartGrid. The original development of the software platform was supported by the U.S. Department of Energy's Advanced Research Agency, ARPA-E. There are revolutionary changes going on in the area of energy. With the appearance of many distributed energy resources, we are moving away from the centralized power station transmission system, distribution system, customer model. We are changing to a more distributed and decentralized paradigm where energy is produced and distributed locally, possibly shared across the grid. We started building microgrids with solar and wind generation playing an increasing role. This leads to increased decentralization and enables cheaper and cleaner energy, but this also introduces problems. New technologies are needed to manage and protect the grid. However, the control architecture of the power grid has not changed yet. The old model of centralized control driven by a control room still applies. Power devices at the edge, such as transformers, capacitor banks, and even loads, are remotely controlled. A new, very dynamic and distributed energy production and distribution paradigm does not mesh well with this. Control or production decisions should be made locally. Systems, which include inverters and substations, need to be integrated and interoperate seamlessly. Today, software is becoming the universal integration tool. This means we need to implement complex, distributed real-time software that is resilient and secure. But how should this be done? Vision with REAPS is to provide a software platform that enables the design, engineering, and operation of such software systems. REAPS is a middleware, a sort of distributed operating system that runs on networked embedded devices deployed on the energy grid. On one side, the platform interacts with sensors like PMUs and actuators such as inverters. And on the other side, it allows communication between the pieces of the distributed app. REAPS apps are inherently distributed and run in loosely coupled, interacting actors that are low overhead containers of single or multi-threaded software components. This is a list of features in REAPS. First of all, REAPS is a software platform to build real-time embedded apps. The apps can run with real-time priority to meet timing constraints. The components of the app interact with each other via high-performance messaging primitives that support various communication architectures such as Pub-Sub and Request-Apply, etc. Components are single-threaded and all interactions among threads happen through messages. REAPS apps can be implemented in Python for soft real-time or in C++ for hard real-time or as a mixture of the two. REAPS provides a number of services that apps can rely on. These include a fault tolerance peer-to-peer discovery service, high precision, approximately 10 microseconds, time synchronization, application deployment, and remote management device access control. Resource management of CPU, file space, network bandwidth, and memory footprint can be tightly controlled, so runaway apps do not exhaust resources. Mechanisms are available for fault tolerance, such as automatic app restart and network link reconnect. REAPS also supports a set of distributed coordination services, which include dynamic group formation and communication, leader election and consensus, and time-coordinated control actions. Finally, REAPS is secure. The deployment mechanism and all communications use secure protocols, and apps are strictly isolated from each other and their access to resources such as network link and devices are tightly controlled. This figure summarizes the layers of the platform. REAPS runs on Linux with real-time extensions enabled and uses standard Linux packages. Its two main ingredients are the component framework that supports the app components and the platform manager that implements the services. Apps are built on top of the framework and rely on the services. Example apps include distributed SCADA, power management, microgrid control, energy management, remedial action scheme. REAPS is designed to be universal and it can support a large variety of embedded apps. To summarize, REAPS is a software platform. We have demonstrated it in a few selected application areas. Microgrid control, remedial action schemes, and transactive energy. Additional information is available on our website. Next, we will show a demo to illustrate how REAPS apps are built, deployed, and run. In this demonstration, we will show a simple application called the distributed estimator. We will utilize Eclipse to demonstrate this. We will open the model file first. This model file has an application name distributed estimator. There are message topics, sensor ready, sensor query, sensor value, and estimate. Three components, a sensor component, a local estimator, a global estimator. The sensor component is defined with a periodic timer that runs every one second. A publish port publishes on the topic of sensor ready. The local estimator has a subscriber that is looking for that topic, sensor ready. There is a request port in the local estimator with a sensor query, sensor value pair, a reply port on the sensor which has matching topics. The local estimator publishes an estimate which is picked up by the global estimator subscriber looking for that same topic. The global estimator also has a timer every three seconds. Actors are executables defined by combinations of one or more components. The estimator actor has a combination of the sensor component and the local estimator. The local messages are messages that stay within the node. Here is where you can see the sensor with its publish sensor ready data and with the local estimator which is subscribing to that information. The sensor query and sensor value request reply ports exchange messages within that actor. The aggregator actor has one component, the global estimator. The estimate messages are global and will be received from the published information of the local estimator. The global estimator is woken up every three seconds using a timer. We'll now look at what it takes to define a component. Looking at the sensor component, the sensor class will define a timer port called clock with an on clock function. Within the on clock function, a message is published using a port called ready. The sensor also has a request port which responds to requests from other components. Next we will look at the local estimator component. The local estimator subscriber port ready is triggered when a sensor ready message is received. It then sends a request on the query port to the sensor. The sensor receives the request on its request port and sends back a response. The response triggers the query port. Then the local estimator will publish an estimate which is available globally. Now let's look at the global estimator component. This component includes a timer that wakes up every three seconds. There is also an estimate subscriber port which is triggered when estimate messages are received from the local estimator. Next we'll show how to start the REAPS controller and a REAPS node. The REAPS registry service is started first. This service could be started in the background as a system service. We will start the REAPS controller application on the development machine. The application will be used to load the REAPS apps, to deploy them to REAPS targets and to start and stop the applications. We will start the deployment service on the development machine. The IP address of the deployed target node will appear once the REAPS framework discovers the node. Now open a REAPS application by first selecting the application folder. Then the model file for the application, the dot REAPS file and the application deployment model dot D E P L. By selecting the view button you will get a picture of the applications architecture and deployment. In this you see that the two actors, the aggregator and estimator are both deployed on the same node. The estimator contains the sensor and the local estimator. You can see the messages and how they are exchanged among the components. You can also tell whether they are local or global messages. The application deployment model shows that we will deploy both actors on all target nodes. Using the deployment model, the controller will deploy the actors to the specified node. Using the REAPS controller we will launch the application. The application is then launched by the REAPS deplo service on each of the target REAPS nodes. The REAPS deplo service output shows messages coming from each component, global estimator, local estimator and sensor. You stop the application by selecting the application and the stop button. You can also remove the application from the REAPS target. This will remove all of the files for this application. We will now run this application on a virtual network which will have four target nodes. Looking at this deployment model you will see that the estimator actor will be deployed on three nodes. The aggregator actor is deployed on the fourth node. We will now launch Mininet with four virtual nodes. We log into each of the virtual nodes and start the REAPS platform. We also start a REAPS controller. This gives you a display window for the control app, three estimators and an aggregator. You can see all four target nodes indicated in the control app. We locate and open the REAPS application as before. But this time we choose the Mininet version of the deployment model. If you again view the application, this time you will notice that there are four target nodes. Deployed onto one target node is the aggregator actor. On the other three is the estimator actor. This time you will see three target nodes contributing estimates that are gathered by the aggregator. There's a corresponding window for each of these nodes. We will now deploy and launch the application on the virtual network. Once it is running you will see one aggregator and three estimators. Aggregator actor log can be viewed in the top window while the other three windows show the estimator actor logs. We will now stop the application. Once they have grayed out then we can safely remove the application from the target node. We can shut down all registered target nodes by selecting kill from the selection menu. Then we can safely quit the control application. For more information on how to use REAPS in your next power application please visit our website.