Dr. David Bakken’s Bio Blurb & Current Seminar Abstracts
Summer 2026
Note: hosts should feel free to condense any verbiage below to meet requirements for length/space. I’m not super picky, so you don’t need to send it back to me to approve your edits. Also, for audiences in China, more time should be allocated because many in the audience will not be native speakers, or close.
Contents
1. GridStat
(60 or 90 minutes)
2. Grid
Decentralization (60, 90, or 120 minutes)
3. Distributed
Computing Overview for Engineers (60 or 90 minutes)
4. Distributed
Coordination (60 or 90 minutes)
5. Middleware
(60, 90, or 120 minutes)
Dr. David Bakken is Professor Emeritus of Computer Science at Washington State University. His research interests include wide-area middleware and dependable computing. Since 1999, he has worked very closely with WSU’s US top-3 electric power research program on developing better data delivery for the bulk (wide-area) power grid and is considered the leading expert on this. Before 1999 he was a research scientist at BBN, the research lab that build the first internet (the ARPANET) in 1969 and researched the first middleware starting in 1979. The QuO middleware framework for WAN QoS and adaptation has flown in Boeing experimental aircraft, been cited close to 2000 times, and been used in multiple DARPA programs. Dr. Bakken chaired a panel on cloud computing for the grid at IEEE Innovative Smart Grid Technologies (ISGT) in 2014 and on Edge computing in 2018. He organized a new workshop, Trustworthiness of Smart Grids (ToSG), at DSN 2014, the premiere international conference on dependable computing; the next iteration was at ISGT 2015. For more info see tosg-workshop.org.
Note: seminars’ times below include questions/discussion. But if there is more time, I can certainly give more details, ask more thought-provoking questions, lead more discussion, etc. as the audience wishes.
Also, these seminars are targeted to a mixed power engineering & computer science audience. I can give different versions to both power engineers and computer scientists. Indeed, I did this (both audiences, with a different focus, on the same days) at both Georgia Institute of Technology and Arizona State University in the past.
Note: there is a little overlap in a few of these seminars … but I postulate that this won’t be fatal to any viewers, though YMMV, and thus we can consider this all to be a medical experiment.
Title: Towards More Effective and Resilient Power Apps Exploiting Modern Communications and Computational Resources
Abstract: Power grids are unique in that supply and demand must be balanced in real time over a few thousand kilometers or more. These grids are getting increasingly stressed and are relying more heavily on power application programs with extreme requirements on the communication system. This seminar first describes the questions that power researchers need to ask themselves to exploit the much better communications and computation (including the cloud) that has been available for the last decade or two. It then overviews these applications and their requirements and appropriate implementation tradeoffs, which are quite different from any other domain and the internet at large. Next the GridStat publish-subscribe system is described, and its grid-appropriate security mechanisms explained.
Title: Grid Decentralization: Trends, Challenges, and Solutions
Abstract: It has long been well-known that power grids are getting more stressed due to many factors including inadequate transmission line growth, renewables that don’t provide rotational inertia, and larger sets of system variables. The decentralization of the last decade or more is adding more stress due to factors that include prosumers and semi-independent microgrids. Indeed, the speed that disturbances travel has gone from 100 miles/hour in 2000 to 1000 miles/second in 2025, a speedup of over 2 orders of magnitude. In this seminar, I will overview these issues and additional challenges that decentralization imposes on grids, including local-only control will then discuss using the distributed computing concept of cooperating groups and how they can be (re)formed with physical, cyber, or cyber-physical criteria. I then will overview 3 case studies: decentralized linear state estimation, decentralized remedial action schemes (RAS), and decentralized voltage stability. I then will overview distributed consensus/agreement that has been researched by distributed computing researchers for almost 50 years and motivate its need for decentralized power grids (the details of which are an entire other seminar).
Title: A Glimpse of Distributed Computing
Abstract: Computer networking gets bytes of data from Point A to Point B with some statistical properties (delay, bandwidth, drop rate, …). Distributed computing (DC) evolved in the late 1970s to figure out how this: how, then, do we best use networks to program distributed application programs? I.e., how do we replicate, synchronize, coordinate, send data structures between computers, etc. From this arose middleware, consensus/agreement protocols, and many other distributed algorithms.
In this seminar I will give the attendee a good sense of what distributed computing is (I note that I am an applied DC researcher, not a theory-only one which is what 80% or more of them are). First, I will quickly overview the history of distributed computing, to give it context. I then will introduce basic DC concepts and explain the difference between a local call (to a procedure in the same address space) versus a remote one. We will also touch on how heterogeneity (diversity of resource types: CPUs, network technologies, programming languages, operating systems) that is inherent to DC. I will then explain middleware, software that handles many difficulties of programming a DC and has been considered best practices in virtually every industry but the power sector since the 1990s or earlier. I will then explain how middleware is often used not for a green field opportunity -- creating services and apps from scratch -- but rather to integrate legacy systems. I will then compare programming with middleware to the only other option for DC: programming using the network socket interface. I then will conclude with discussion and questions.
Title: Distributed Coordination (If Secure and Smart) Enables the IoT and Power Grid Coordination
The Internet of Things (IoT) movement posits a pervasive ensemble of formerly dumb and unconnected devices enabled not only with communications but also with (presumed) intelligence. Our society is rapidly moving in this direction, for better or worse. In many IoT application domains, and also electric power, it is not just communication per se but also coordination that is fundamental. Unfortunately, domain specialists in almost every domain have zero background in, or even know of the existence, of distributed computing, let alone distributed coordination. Worse, most distributed coordination papers (since 1978) have mostly seemingly never been implemented: they were written by theory-only professors writing to convince other theory-only reviewers of the properties of their algorithms, not giving pseudocode or anything close. They are thus utterly inaccessible to IoT practitioners and power engineers. In this presentation, we will overview coordination challenges inherent in the IoT vision. We will deeply overview such challenges in the electric power grid, and overview them in other domains, including UAVs and connected vehicles. We then describe how platform support for such coordination can be an enabling technology for IoT; we call this IoT-Coord. Next we give published examples of power applications: decentralized linear state estimation, distributed remedial action scheme(RAS); and list (other published) others: distributed voltage stability, distributed state estimation, distributed wind power monitoring and control, distributed frequency control, decentralized optimal power control, decentralized reactive power control, and decentralized inverter control; and what coordination primitives they used. We then discuss how such platform support must inherently support AI/ML plugins and domain/application-specific security and a managed runtime system.
Title: Middleware
Middleware is a class of software technologies designed to
help manage the complexity and heterogeneity inherent in distributed
systems. It is defined as a layer of software above the operating system
but below the application program providing a common
programming abstraction — such as distributed objects, events, tuples, and
others — across a distributed computing system. In doing so, it provides
a higher-level building block for programmers than Application Programming
Interfaces (APIs) such as sockets that are provided by the operating system.
These APIs also support type checking and exception handling, which
significantly reduces the burden on application programmers by relieving them
of this kind of tedious and error-prone programming. This makes resulting
programs more resilient.
Middleware frameworks are designed to mask some of the
kinds of heterogeneity (resource diversity) that programmers of distributed
systems must inevitably deal with. They always mask heterogeneity of
network and CPU technologies. Most middleware frameworks also mask
heterogeneity of operating systems or programming languages, or both. A
few such as the OMG’s CORBA and DDS also mask
heterogeneity among vendor implementations of the same middleware standard.
This can be VERY helpful for long-lived systems (such as military or power
grid): if one vendor goes out of business, it is possible (but not for for free) to “change horses midstream” and use another
vendor’s implementation of the same standard. Finally, programming
abstractions offered by middleware can hide the distribution in one or more of
the following dimensions: location, concurrency, replication, failures, and
mobility.
In this seminar, I will quickly overview distributed
computing systems for context. I then explain the basics of middleware, and
multi-layered middleware. I then will provide a case study of CORBA’s remote
object middleware. Finally, I overview Quality Objects (QuO),
a sophisticated object-oriented system providing multi-dimensional quality of
service (QoS) that I was a DARPA co-PI on in the 1990s. It had approximately
50-60 person-years of BBN labor invested in it by DARPA, and about 3X that from
collaborating partners including Georgia Tech, CMU, Honeywell Labs, and many
others. It was the key integrating technology for the DARPA Quorum program, and
a prototype was demonstrated ca. 1997 to the Navy that integrated 7-different
organizations’ QoS-related technologies, which was (and still is) virtually
unheard of.
For
a quick overview of the benefits of middleware, see this encyclopedia Dr.
Bakken wrote: https://eecs.wsu.edu/~bakken/middleware.pdf. Its first page give a solid
semi-technical overview of what middleware is and its huge benefits,
understandable even by non-technical and/or pointy-haired Dilbert managers. It
was written more than a quarter century ago(!!!) so
some of the technologies mentioned are somewhat out of date. However, by then
middleware had been considered best practices in all industries but the power
sector for at least 10 years, and 20+ for the military (especially Air Force);
its genesis was a 1967 software engineering report from NATO., and the first middleware
research was started by Dr. Bakken’s BBN mentor, Dr. Richard
Schantz, in 1979.
Title: Linda, FT-Linda, and Jini
Linda is a coordination language that augments an existing computational language such as C to help simplify parallel programming developed by David Gelertner at Yale in the 1980s. When distributed, it is an example of what is now called middleware. It provides the abstraction of tuple space (TS), an unordered bag of tuples. TS consists of a logical name and zero or more typed values. Linda adds primitives to the base language to use TS: adding or removing tuples from TS, etc. TS is an associative, distributed shared memory.
In this presentation, I first overview Linda and some canonical examples of using it. Next, explain problems that occur in the presence of failures. Next, I describe FT-Linda, a fault-tolerant version of Linda that uses the state machine approach via fault-tolerant ordered multicast and give examples of using it. After this, I describe Jini, a framework from Sun Microsystems (creator of Java) that allows groups of services and users to federate into a single, dynamic distributed system called a Jini Community. Finally, I overview JavaSpaces, which is built on top of Linda and which Jini is based on and supports both strong typing and object-oriented programming.
Title: Quality Objects: Middleware-Level Multi-Dimensional QoS for Adaptive WAN Apps
Abstract: Quality of Service (QoS) deals with the issues of performance, available, and security that are outside of a program or service’s “business logic”. This seminar overviews the Quality Objects (QuO) middleware, developed at BBN Technologies from 1995 until the mid-2000s. QuO handles QoS issues at the middleware layer, and supports “reserving” network bandwidth and replicas to enhance performance and availability, respectively. It does so in a way that allows applications to adapt to changing resource availability, changing mission phases with new requirements, cyber attacks, etc.
QuO had approx. 60-70 person-years of BBN labor invested in it, mainly by DARPA, and about 3 times that money invested in research collaborators who used it, including Georgia Tech, University of Illinois, Cornell University, Washington University in St. Louis, Columbia University, Trusted Information Systems, Honeywell Labs, Boeing Phantom Works, and others. It has flown in Boeing experimental aircraft; developed and used in 7 DARPA ITO and ISO QuO CONTRACTS, was evaluated for use with UAVs (drones); etc.. QuO was used in a demo for the US Navy (SPAWAR) to integrated 7 QoS-related technologies from 6-7 organizations, this scale was unheard of, but is precisely what QuO was designed to do.
Indeed, helps system builders create adaptive and resilient distributed applications and services. To do this, it integrates into a coherent framework many QoS-related mechanisms and meta-data in a coherent extensible framework, including QoS mechanisms (bandwidth reservation, replica management), adaptive application behaviors, and many more. This allows system builder to help master the inherent complexity of such complex systems. QuO also extracts simplicity out of this complexity by supporting mini languages (which generate middleware code) to specify QoS contracts, delegates (QuO proxies/stubs), runtime initialization, adaptive behavior, and other facets. These languages are in the spirit of Aspect-Oriented Programming.
Note: This is very advanced distributed computing: when teaching an advanced graduate class on this subject, I ALWAYS start out with this, because it identifies so many issues in the context of a well-thought-out framework. Indeed, a leading QoS researcher at Illinois told me that when she teaches a graduate class on QoS, she always starts with QuO. But, unless someone has taken a class in distributed computing, or at least attended my one-day distributed systems bootcamp, they are likely to get not much out of this lecture in specific, but they will gain a good sense of the scope of the complexities in wide-area distributed computing and complex infrastructures to help monitor and manage them.