Women and Engineering: A Story for your Daughter 1

Recently, I got the opportunity to present to a group called, “Women Who Code (WWC),” a society for women in software engineering careers. I decided to start with a story that I made up for my daughter when she was little. The kid’s version is contained at the bottom of this post; if you have time, please check it out. But, since you’re likely a harried grown up, here’s the Reader’s Digest version: 

Once upon a time, there was a beautiful princess named Julina living in a castle on a lake. High on a nearby mountain lived a valiant prince who admired the princess from afar. But she ignored him; she was too busy collecting things and playing in her room.

Then one day a dragon comes to the valley and attacks the town by the lake. The prince sees his chance to prove himself to beautiful Julina. So, he grabs his sword and armor, and rushes down to the lake to battle the dragon.

You know the drill: fierce dragon against great swordsman. There’s a clash of fire and scales and dagger-like teeth, against training, agility and determination. In the end, the prince sinks his sword deep into the dragon’s soft underbelly. Dragons always have soft underbellies.

Unfortunately, the dragon just pulls out the sword, scoops up the prince and takes him up to his lair for lunch.

But, before the dragon could eat Sir Loin of Beef, he’s distracted by a loud noise from the lake. The dragon goes down to investigate and finds Julina zooming across the water on a roaring machine!

You see, it turns out that Julina is an engineer. She wasn’t collecting and playing in her room, she was inventing a jet ski with a water cannon. Well, the dragon attacks, doesn’t do so well, and Julina saves the day and the prince. Everyone lives happily ever after. The End.

My daughter loved that story.

My daughter starts her PhD In Aerospace Engineering at Stanford this fall.

I did a bit of research on RTI’s amazing women for this talk as well. I found that for each of the last two years, our highest-paid employee was a woman.  Fully 50% of our engineering development managers are women. These are great stats. They were well received by the WWC.  But they missed my point.

My point was not that women can succeed. That should be obvious. The “Women Who Code” should not even have to exist. Of course women can code. Of course women can manage engineers. Of course women can make more money. Of course women can get engineering PhDs at Stanford. These should not be twists in our story. These should be boring normality.

Then I realized these are hardly the only twists in RTI’s story. We find things that don’t make sense everywhere we look. Some examples:

In 2015, the Institute of Medicine reported that hospital error is the third leading cause of death in the United States after heart disease and cancer. Why? Hospitals perform many complex operations and procedures and use hundreds of sophisticated instruments and devices, like ventilators and respirators and ECG monitors and oximeters. However, today’s instruments are standalone devices; they don’t even know that they’re connected to the same patient. So, they can’t check on each other. With high patient loads, useless alarms and manual checklists, harried care teams make mistakes. And that kills between 220,000 and 440,000 people a year.

RTI software helps. Our customers like Harvard Medical School and GE Healthcare are connecting smart algorithms to networks of devices. Connected devices can work together to monitor patients much more intelligently, preventing thousands and thousands of mistakes. The distributed intelligent system of devices can join and help the care team.

Isolated systems also plague the power industry. Today’s grid consists of huge generators controlled by a central office. This design can’t deal with “distributed energy resources” like solar and wind. One main reason: big generators can’t react fast enough to efficiently use the variable power flow from these renewable sources.

Connectivity also helps here. For instance, RTI runs the largest hydropower plants in North America.  Hydropower is an ideal complement to solar and wind: it’s faster responding, more predictable and more reliable than other “base capacity” generators. RTI also controls large wind farms, such as Siemens Wind Power’s most advanced wind turbines, with thousands deployed worldwide. And, we are a principal in the leading new grid standard to replace central control with distributed field networks for solar, wind and batteries. Networked together, renewable sources can combine to provide the consistent, reliable power we need to meaningfully reduce our dependency on fossil fuels.

But, my favorite twist in the technology story is autonomous drive cars, or “carbots.” I started my career crashing cars doing impact testing. Back then, 45,000 people a year were dying on our highways. Last year, 35,000 died. That’s better, but it’s hardly good enough. Carbots will finally replace the weakest safety system: drivers cause 94% of all fatal accidents. We originally developed our “databus” technology for autonomy (flying robots). Now, it’s great for intelligent carbots. 

In the end, RTI fights the dragons of convention every day. Convention says 400,000 people will die unnecessarily in hospitals every year. Convention says we have to burn things for power. Convention says it’s OK to sit in traffic for countless hours and kill tens of thousands of people on our roads every year.

Convention also says most engineering managers are men. Convention says women don’t earn as much. Convention says women rarely get PhDs in engineering. And convention says women don’t code.

Convention is wrong. It’s not always fast and it’s not ever easy, but convention is changing.  I’m truly grateful to the Women Who Code for inspiring women to seek careers changing these outdated conventions. And for inspiring me to brag about RTI’s amazing women, and maybe even attract more. We certainly need them; our women are not paid well or managing teams because we preferentially pay or promote.  They are just damn good.

They prove women can excel in any career.

And little girls can grow up to slay dragons.

 

The Princess and The Dragon

Once upon a time, there was a beautiful princess named Julina. Julina lived in a big castle on a river. This wasn’t an ordinary castle on the shores of a river, Julina’s castle was built on a bridge over the river. The river went right through the bottom of the castle. Julina’s room was on the second floor; she had a big window with a view up the river. But, her window was always closed and covered with shutters.

Julina collected everything. Well, maybe not everything, but lots of things. She collected old shields, swords, and armor from the knights. When the farmers brought their crops to the market outside the castle, they would bring extra corn husks for Julina. She got wheels, rods and metal from the blacksmith. She even went to the kitchen and got grease, candles, old pans and anything else she could find.

She took all these things up to her room. She didn’t tell anyone what was going on in there, but they heard banging, and pounding, and whirring, and scraping, and scratching, and clanking, and clunking, and swishing, and bubbling, and even some screeeeeeeeeeeeeeeching.

Julina liked to play in her room, but Julina’s favorite thing of all was her pretty white dress. Every afternoon, Julina would put on her dress and walk around the castle and the garden. Her dress went all the way down to the ground, with poofy sleeves and pretty flowers sewn down the front, and a hundred buttons down the back. She loved her dress.

Down the river a little bit from Julina’s castle, the river went through a canyon between two big mountains. At the top of one of the mountains there was another castle as big as Julina’s. In that castle, there was a Prince named Phillip — the biggest, strongest, bravest knight in all the kingdom. Prince Phillip was a great hunter and a great swordsman. He could ride his horse better than any knight. And he could even cook.

Every afternoon, Prince Phillip would look through his telescope at the castle built over the river below. He saw Julina in her beautiful white dress. She was soooo pretty. He really wanted to meet her, somehow.

One day, all of a sudden, the earth shook! There was a terrible noise, like a train crashing into a tornado and rolling down a mountain over a pile of rocks and squirrels. The mountain across the river from Phillip’s castle cracked! Tons of rock came crashing down, splashing right into the river. It blocked the river and the river started to turn into a lake.

The lake was growing and growing, getting big enough to cover the gardens around Julina’s castle.  Everyone was scared that the castle would be underwater soon. But suddenly, a screech came down from the top of the broken mountain! Everyone looked up, and there was a HUGE dragon coming out of the mountain! The dragon had bright golden scales, a huge sharp tail, and big green wings. Its huge mouth was filled with crystal dagger teeth, so clear you could see right through them and so sharp you could see the sun glint from every one. And when it screeched, it breathed a huge blast of fire!

The dragon swooped down from the mountain and wheeled over the lake that was now deep enough to cover the bottom floor of Julina’s castle. Prince Phillip grabbed his sword and jumped on his horse. He charged down the mountain to save Julina!

When he got to the castle, the dragon attacked. It swooped down, with its claws out and fire shooting out. Prince Phillip blocked the fire with his shield and stabbed the dragon with his sword! But the sword just bounced off the golden scales.

The dragon came back around, zooming low and fast. Prince Phillip dove on the ground and held up his sword. When the dragon flew over, he slashed at the dragon’s throat!  But the sword just bounced off the golden scales again. But, when it flew over, Phillip noticed that the dragon had a dark underbelly, with no golden scales.

The dragon went way up high in the sky.  It dove straight down at Phillip at 100 mph, screaming all the way. Fire shot out. The dragon’s claws aimed right at Phillip. The crystal dagger teeth shone like a thousand suns. Phillip knelt down on the ground, his sword out, aiming for the soft underbelly. The dragon swooped. Phillip stabbed!  The sword went right into the dragon’s underbelly!

But, then the dragon ripped the sword out with one claw and grabbed Phillip with the other one! It flapped its great wings and flew up to the top of the broken mountain. It dropped Phillip on a rock and opened its great mouth to eat him for its supper! Everyone below heard Phillip yell: “Help! Help!” Phillip was in trouble.

Just then a roar arose from below. Brrriiinnnnnnndddd-din-din! Julina’s shutters flew open, broken glass blasted out and Julina came roaring out on a machine on the water!  You see, Julina was an engineer, and she had invented a jet ski, and built a motor and turned the corn husks into fuel. Her jet ski made a huge roar unlike anything ever heard in the kingdom as she shot across the lake.

The dragon heard the noise. It took off and swooped down across the lake, straight for the jet ski. Julina turned towards the dragon!  The dragon shot out a stream of fire. Julina turned her jet ski just in time, splashing the dragon with water.

That made the dragon even madder. He swooped way up high over Julina’s castle, and started a screaming dive. Fire shot out. The dragon’s claws aimed right at Julina. The crystal dagger teeth shone like a thousand suns. Julina turned her jet ski straight at the dragon and hit the gas hard. Brinnnnnddddd-din-din! Brinnnddd-din-din!

The dragon came screaming in low across the lake, shooting a huge, hot flame. Then, Julina pulled a lever on her jet ski, and a long black tube came up. It curved towards the dragon. It said F—P—X! Fish Poop Express!!!!!!! The bottom of the tube went deep into the lake. It sucked up water and muck and fish poop, and shot it straight at the dragon!

The water and muck and fish poop hit the dragon! It put out its fire and smacked it right in the face! It couldn’t see! It shot right over Julina, swerved a bit left, a bit right, up a bit, down a bit, and right into the rocks that were blocking the river! Scales went everywhere!  The crystal dagger teeth shattered into a million zillion pieces, flying miles away in every direction. The rocks flew away, breaking the dam, and all the water went rushing down the river.

The castle was saved! The dragon was dead! Phillip didn’t get eaten! Everyone at the castle on the river yelled “YAY!” Everyone at Phillip’s castle yelled “YAY!”

Phillip climbed down from the mountain. He had to talk to Julina, and thank her for saving his life. She was the most amazing girl he’d ever seen. On his climb down, he found a piece of dragon’s tooth, a crystal-clear piece harder than any rock. He found a piece of golden scale. He shaped the scale into a ring and put the dragon’s tooth on top. Then he went to ask Julina to marry him.

She said yes, and he gave her the ring. She wore her pretty white dress to the wedding and they lived happily ever after.

And to this day, when people get married, they get a ring made of dragon scales with a piece of dragon tooth on it. The tooth is crystal clear and harder than any rock. When the sun shines on it, you can see the flash of fire that came from the dragon’s mouth. And the bride wears a pretty white dress.

The End.

Postscript: I used to ask my kids to give me three or four things, and I would tell them a story that included them all. This story was the result of the set: a princess, a dragon, a jet ski and fish poop.

© Stan Schneider

#TBT: From Predicting to Propelling the Industrial IoT Reply

If you missed it, you should check out the recent press release about RTI’s growth in the Industrial Internet of Things (IIoT). It’s really a great time to be RTI! Sure, from a business perspective all the vectors point the right way. But for me, the most exciting things in that press release aren’t numbers.  I’m more amazed that we get to play with so many futuristic applications. Carbots? Renewable energy? Smart healthcare? Hyperloop? Flying cars? Wind turbines? CT scanners? We got ‘em all. And new things show up all the time.

How can a small company like RTI play in so many areas? It’s Thursday, so in honor of #TBT, I thought I’d take a look back and see how we got here.

For those of you RTI history buffs, we sold our tools business to Wind River in 2005. It was 80% of our revenues at the time. So, in 2006, we had some money and great people, but not much in the way of products. So, we started looking for new trends. What did we find? Here’s an excerpt from our 2006 vision paper called “The Data-Centric Future”:

Truly profound technologies become part of everyday life. Motors, plastics, computers, and now networking have made this transition in the last 100 years. These technologies are embedded in billions of devices; they have melted into the assumed background of the modern world.

Another step is emerging in this progression: pervasive, real-time data. This differs from the Internet in that this pervasive information infrastructure will connect devices, not people. Just as the “web” connected people and fundamentally changed how we all interact; pervasive data will connect devices and change how they interact.

Today’s network makes it easy to connect nodes, but not easy to find and access the information resident in networks of connected nodes. This is changing; we will soon assume the ability to pool information from many distributed sources, and access it at rates meaningful to physical processes.  Many label this new capability the “network-centric” architecture. We prefer the term “data centric” because the change, fundamentally, is driven by a fast and easy availability of information, not the connectivity of the network itself. Whatever the name, it will drive the development of vast, distributed, information-critical applications.

If you change “pervasive information infrastructure” to “Industrial IoT,” that was a pretty good prediction. Too bad the name didn’t stick, but I suppose “PII” sounds more like the second act of a play or a stuttering math teacher than a technology revolution. Anyway, we thought it was coming soon, but 6 years later, we were still predicting. An RTI handbook entry from 2012 (still before the IoT and before the IIC launched the Industrial IoT in 2014) expanded on this a bit:

There is amazing value in distributed information. Connecting people to information transforms society – news feeds, weather satellites, and the Internet are only a few examples – timely information flow drives value in every industry and every endeavor.

However, current technologies only connect people at human speeds. There’s an entirely new opportunity to connect machines at physics speeds. Just as the Internet connected people and fundamentally changed how we all interact, a new “pervasive information infrastructure” will connect devices at speeds fast enough to drive distributed applications. RTI’s people and technology are the best in the world at delivering that data to the right place at the right time. We fundamentally connect complex systems at extreme speeds better than any organization on the planet.

Our technology enables tens, or hundreds, or thousands, or (soon) millions of processors to work together as a single application. Why does that matter? Because intimately-connected systems can do things that weakly-connected systems cannot. They can request and access data from far-flung reaches fast enough to react intelligently. They can read deeply-embedded sensors, use that data to control high-speed machines, and feed the results to the enterprise for monitoring and optimization. This powerful connectivity is a fundamental transformation that will make currently difficult things commonplace and currently impossible things possible. We are already working on many of these applications. Our work will help astronomers probe the deepest reaches of space, protect passengers from injury on tomorrow’s roads, make our nation more secure from attack, and improve the efficiency of renewable energy generation. RTI is leading the new wave of large connected systems, systems that work together as one.

So how can we play in so many futuristic areas? Call us lucky or call us prescient, but the IIoT has been our target for over a decade. RTI is influential in the IIoT because we got a head start. We’re no longer predicting. We’re now realizing the future.

So, what’s next? Our new tagline is “RTI lives at the intersection of functional artificial intelligence and pervasive networking.” Think about that one for a while. AI and connectivity are perhaps the most important trends for the next 40 years. They will combine to bring new wonders to light in every industry on the planet. The IIoT is much more than a name or a connectivity technology; it’s a new infrastructure for, well, everything. Connecting things together is powerful. Connecting those things to smarts is a whole new game. Carbots will improve transportation, autonomous hospital devices will take better care of patients and smart networks will make green energy practical. But, these are just the ENIACs of the IIoT. It won’t be long until every device on the planet is part of a connected, intelligent infrastructure. That infrastructure will make everything more efficient, more useful and friendlier.  These are exciting times indeed!

In any case, it’s an honor to be a leader in the “new” IIoT revolution. It’s even more of an honor to be associated with the technical visionaries at RTI that put us there.

A Foggy Forecast for the Industrial Internet of Things Reply

A Foggy Forecast for the Industrial Internet of Things

Signs on I-280 up the San Francisco peninsula proclaim it the “World’s Most Beautiful Freeway.” It’s best when the fog rolls over the hills into the valley, as in this picture I took last summer.

That fog is not just pretty, it’s also the natural refrigerator responsible for California’s famously perfect weather. Clouds in the right place work wonders.

What is Fog? iiot-glossary

This is a perfect analogy for the impending future of the Industrial Internet of Things (IIoT) computing. In weather, fog is the same thing as clouds, only close to the ground. In the IoT, fog is defined as cloud technology close to the things. Neither is a precise term, but it’s true in both cases: clouds in the right place work wonders.

The major industry consortia, including the Industrial Internet Consortium (IIC) and the OpenFog Consortium, are working hard to better define this future.  All agree that many aspects that drive the spectacular success of the cloud must extend beyond data centers.  The also agree that the real world also contains challenges not handled by cloud systems.  They also bandy about names and brand positioning; see the sidebar for a quick weather map.  By any name, the fog, or layered edge computing, is critical to the operation of the industrial infrastructure.

Perhaps the best way to understand fog is to examine real use cases.

Example: Connected Medical Devices

Consider first the coming future of intelligent medical systems.  The driving issue is an alarming fact: the 3rd leading cause of death in the US is hospital error.  Despite extensive protocols that check and recheck assumptions, device alarms, training on alarm fatigue, and years of experience, the sad truth is that hundreds of thousands of people die every year because of miscommunications and errors.  Increasingly clearly, compensating for human error in such a complex environment is not the solution.  The best path is to use technology to take better care of patients.

The Integrated Clinical Environment standard is a leading effort to create an intelligent, distributed system to monitor and care for patients.  The key idea is to connect medical devices to each other and to an intelligent “supervisory” computing function.  The supervisor acts like a tireless member of the care team, checking patient status and intelligently alerting human caretakers or even taking autonomous actions when there are problems.

icedataflow

The supervisor combines and analyzes oximeter, capnometer, and respirator readings to reduce false alarms and stop drug infusion to prevent overdose. The DDS “databus” connects all the components with real-time reliable delivery.

This sounds simple.  However, consider the real-world challenges.  The problem is not just the intelligence.  Current medical devices do not communicate at all.  They have no idea that they are connected to the same patient.  There’s no obvious way to ensure data consistency, staff monitoring, or reliable operation.

Worse, the above diagram is only one patient.  That’s not the reality of a hospital; they have hundreds or thousands of beds.  Patients move between rooms every day.  The environment includes a mix of wired and wireless networks. Finding and delivering information within the treatment-critical environment is a superb challenge.

A realistic hospital environment includes thousands of patients and hundreds of thousands of devices. Reliable monitoring technology must find the right patient and guarantee delivery of that patient’s data to the right analysis or staff. In the connectivity map above, every red dot is a “fog routing node”, responsible for passing the right data up to the next layer.

A realistic hospital environment includes thousands of patients and hundreds of thousands of devices. Reliable monitoring technology must find the right patient and guarantee delivery of that patient’s data to the right analysis or staff. In the connectivity map above, every red dot is a “fog routing node”, responsible for passing the right data up to the next layer.

This scenario exposes the key need for a layered fog system.  Complex systems like this must build from hierarchical subsystems.  Each subsystem shares internal data, with possibly complex dataflow, to execute its functions.  For instance, a ventilator is a complex device that controls gas flows, monitors patient state, and delivers assisted breathing.  Internally, it includes many sensors and motors and processors that share this data.  Externally, it presents a much simpler interface that conveys the patient’s physiological state.   Each of the hundreds of types of devices in a hospital face a similar challenge.  The fog computing system must exchange the right information up the chain at each level.

Note that this use case is not a good candidate for cloud-based technology.  These machines must exchange fast, real-time data flows, such as signal waveforms, to properly make decisions.  Also, patient health is at stake.  Thus, each critical component will need a very reliable connection and even redundant implementation for failover.  Those failovers must occur in a matter of seconds.  It’s not safe or practical to rely on remote connections.

Example: Autonomous Cars

The “driverless car” is the most disruptive innovation in transportation since the “horseless carriage”.  Autonomous Drive (AD) cars and trucks will change daily life and the economy in ways that hard to imagine.  They will move people and things faster, safer, cheaper, farther, and easier than the primitive “bio-drive” cars of the last century.  And the economic impact is stunning; 30% of all US jobs will end or change; trucking, delivery, traffic control, urban transport, child & elder care, roadside hotels, restaurants, insurance, auto body, law, real estate, and leisure will never again be the same.

Autonomous car software exchanges many data types and sources. Video and Lidar sensors are very high volume; feedback control signals are fast. Infrastructure that reliably sends exactly the right information to exactly the right places at the right time makes system development much easier. The vehicle thus combines the performance of embedded systems with the intelligence of the cloud…aka fog.

Autonomous car software exchanges many data types and sources. Video and Lidar sensors are very high volume; feedback control signals are fast. Infrastructure that reliably sends exactly the right information to exactly the right places at the right time makes system development much easier. The vehicle thus combines the performance of embedded systems with the intelligence of the cloud…aka fog.

Intelligent vehicles are complex distributed systems.  An autonomous car combines vision, radar, lidar, proximity sensors, GPS, mapping, navigation, planning, and control.  These components must work together as a reliable, safe, secure system that can analyze complex environments in real time and react to negotiate chaotic environments.  Autonomy is thus a supreme technical challenge.  An autonomous car is more a robot on wheels than it is a car. Automotive vendors suddenly face a very new challenge.  They need fog.

Fog integrates all the components in an autonomous car design. Each of these components is a complex module on its own. As in the hospital patient monitoring case, this is only one car; fog routing nodes (red) are required to integrate subsystems and connect the car into a larger cloud-based system. This system also requires fast performance, extreme reliability, integration of many types of dataflow, and controlled module interactions. Note that cloud-based applications are also critical components. Fog systems must seamlessly merge with cloud-based applications as well.

Fog integrates all the components in an autonomous car design. Each of these components is a complex module on its own. As in the hospital patient monitoring case, this is only one car; fog routing nodes (red) are required to integrate subsystems and connect the car into a larger cloud-based system. This system also requires fast performance, extreme reliability, integration of many types of dataflow, and controlled module interactions. Note that cloud-based applications are also critical components. Fog systems must seamlessly merge with cloud-based applications as well.

How Can Fog Work?

So, how can this all work?  I’ve hinted at a few of the requirements above.  Connectivity is perhaps the greatest challenge.  Enterprise-class technologies cannot deliver the performance, reliability, redundancy, and distributed scale that IIoT systems need.

The key insight is that systems are all about the data.  The enabling technology is data-centricity.

A data-centric system has no hard-coded interactions between applications.  When applied to fog connectivity, this concept overcomes problems associated with point-to-point system integration, such as lack of scalability, interoperability, and the ability to evolve the architecture. It enables plug-and-play simplicity, scalability, and exceptionally high performance.

The leading standard for data-centric connectivity is the Data Distribution Service (DDS).  DDS is not like other middleware.  It directly addresses real-time systems. It features extensive fine control of real-time Quality of Service (QoS) parameters, including reliability, bandwidth control, delivery deadlines, liveliness status, resource limits, and security.  It explicitly manages the communications “data model”, or types and QoS used to communicate between endpoints.  It is thus a “data-centric” technology.

DDS is all about the data: finding data, communicating data, ensuring fresh data, matching data needs, and controlling data.  Like a database, which provides data-centric storage, DDS understands the contents of the information it manages.  This data-centric nature, analogous to a database, justifies the term “databus”.

Databus vs. Database: The 6 Questions Every IIoT Developer Needs to Ask

Traditional communications architectures directly connect applications. This connection takes many forms, including messaging, remote object-oriented invocation, and service oriented architectures. Data-centric systems fundamentally differ because applications interact only with the data and properties of data. Data centricity decouples applications and greatly enables scalability, interoperability and integration. Because many applications may interact with the data independently, data centricity also makes redundancy natural.

Traditional communications architectures directly connect applications. This connection takes many forms, including messaging, remote object-oriented invocation, and service oriented architectures. Data-centric systems fundamentally differ because applications interact only with the data and properties of data. Data-centricity decouples applications and greatly enables scalability, interoperability and integration. Because many applications may interact with the data independently, data-centricity also makes redundancy natural.

Note that the databus replaces the application-application interaction with application-data-application interaction.  This abstraction is the crux of data-centricity and it’s absolutely critical.  Data-centricity decouples applications and greatly eases scaling, interoperability, and system integration.

Continuing the analogy above, a database implements this same trick for data-centric storage.  It saves old information that you can later search by relating properties of the stored data.  A databus implements data-centric interaction.  It manages future information by letting you filter by properties of the incoming data.  Data-centricity makes a database essential for large storage systems.  Data-centricity makes a databus a fundamental technology for large software-system integration.

The databus automatically discovers and connects publishing and subscribing applications.  No configuration changes are required to add a new smart machine to the network.  The databus matches and enforces QoS.  The databus insulates applications from the execution, or even existence, of other applications.  As long as its data specifications are met, an application can run successfully.

A databus also requires no servers.  It uses a protocol to discover possible connections.  All dataflow is directly peer-to-peer for the lowest possible latency.  And, with no servers to clog or fail, the fundamental infrastructure is both scalable and reliable.

To scale as in our examples above, we must combine hierarchical subsystems; that’s important to fog.  This requires a component that isolates subsystem interfaces, a “fog routing node”.  Note that this is a conceptual term.  It does not have to be, and often is not, implemented as a hardware device.  It is usually implemented as a service, or running application.  That service can run anywhere needed: on the device itself, in a separate box, or in the higher-level system.  Its function is to “wrap a box around” a subsystem, thus hiding the complexity.  The subsystem thus exports only the needed data, allows only controlled access, and even presents a single security domain (certificate).  Also, because the databus so naturally supports redundancy, the service design allows highly reliable systems to simply run many parallel routing nodes.

Hierarchical systems require containment of subsystem internal data. The fog routing node maps data models between levels, controls information export, enables fast internal discovery, and maps security domains. The external interface is thus a much simpler view that hides the internal system.

Hierarchical systems require containment of subsystem internal data. The fog routing node maps data models between levels, controls information export, enables fast internal discovery, and maps security domains. The external interface is thus a much simpler view that hides the internal system.

RTI has immense experience with this design, with over 1000 projects.  These include fast 3kHz feedback loops for robotics, NASA KSC’s huge 300k-point launch control SCADA system, Siemens Wind Power’s largest offshore turbine farms, the Grand Coulee dam, GE Healthcare’s CT imaging and  patient monitoring product lines, almost all Navy ships of the US and its allies, Joy Global’s continuous mining machines, many pilotless drones and ground stations, Audi’s hardware-in-the-loop testing environment, and a growing list of autonomous car and truck designs.

The key benefits of a databus include:

  • Reliability: Easy redundancy and no servers to fail allow extremely reliable operation. The DDS databus supports systems cannot tolerate being offline even for a short period, whether 5 minutes or 5 milliseconds.
  • Real-time: Databus peer-to-peer delivery easily supports latencies measured in milliseconds and even tens of microseconds.
  • Interface scale: Large software projects with more than 10 interacting modules must carefully define, coordinate, and evolve interfaces. Data-centric technology moves this responsibility from manual processes to automatic, enforced infrastructure.  RTI has experience with systems with over 1500 teams of programmers building thousands of interacting applications.
  • Data scale: When systems grow large, they must control dataflow. It’s simply not practical to send everything to every application.  The databus allows filtering by content, rate, and more.  Thus, applications receive only what they truly need.  This greatly reduces both network and processor load.  This is critical for any system with more than 1000 independently-addressable data items.
  • Architecture: Data-centricity is not easily “added” to a system. It is instead adopted as the core design.  Thus, the transformation makes sense only for next-generation IIoT designs.  Most system designs have lifecycles of many years.

Any system that meets most of these requirements should seriously consider a data-centric design.

FREE eBook: Leading Applications & Architecture for the Industrial Internet of Things

The Foggy Future

Like the California fog blanket, a cloud in the right place works wonders.  Databus technology enables elastic computing by bringing the data where it’s needed reliability.  It supports real-time, reliable, scalable system building. Of course, communication is only one of the required functions of the evolving fog architecture.  But it is key and relatively mature.  It is thus driving many designs.

The Industrial IoT will change nearly every industry, including transportation, medical, power, oil and gas, agriculture, and more.  It will be the primary driving trend in technology for the next several decades, the technology story of our lifetimes.  Fog computing will move powerful processing currently only available in the cloud out to the field.  The forecast is foggy indeed.