By Lance Eliot, the AI Trends Insider
Maybe so, maybe not.
One of the hot topics in the distributed computer systems realm involves notions of consistency.
Simple stated, if you have multiple machines that are intended to store some particular data, what are the various ways that you can keep that data “consistent” across those myriad of machines, meaning that the same data is at those machines whenever you opt to take a look.
This is a lot harder to arrange than it might seem at first glance.
Let’s use an everyday example to illustrate this theme about consistency.
Example Of Consistency Difficulties
Pretend that you have a bank account that has $40 in it.
You go to an ATM that’s in front of a grocery store and use it to find out your current balance. After logging into the ATM, it confirms that you’ve got $40 in your bank account.
Later that day you go to the bank and deposit $60 more into your bank account, doing so at the ATM at the bank branch. You walk away from the bank and proceed on your merry way. In theory, you now have $100 in your bank account, due to adding $60 to the $40 that was already there. You are rich!
Perhaps the bank has a centralized computer that keeps track of all of the deposits made at all of the ATM’s. When you went to the first ATM at the grocery store, it communicated with the centralized system and found out you had $40 in your account, and the ATM then told you so. When you later on went to the ATM at the bank, it dutifully took your added $60 and communicated with the centralized system to tell it so.
Since you are suspicious of banks and all financial institutions, you decide to once again visit the ATM at the grocery store and double-check that the added $60 is really recorded in your bank account. Who knows, maybe the bank has taken your money and used it for a honeymoon trip to Hawaii.
For my article about conspiracy theories, see: https://aitrends.com/selfdrivingcars/conspiracy-theories-about-ai-self-driving-cars/
When you login to the ATM at the grocery store, what do you see?
Well, I’m sure you are expecting to see that you have $100 in your account and that the $60 was properly recorded and added to your balance. Otherwise, it would seem like you’ve been ripped off and somebody’s head should roll.
So that you don’t get overwrought, let’s pretend that indeed the $100 is shown and also the $60 deposit is shown.
The ATM would have communicated with the centralized system, the $60 deposit transaction would have been recorded, and the new balance was calculated. All’s good.
Suppose though that when using the ATM at the grocery store this second time, it shows you that you still only have $40 in your bank account and there’s no indication that you had made the added $60 deposit. Yikes! You are as angry as a hornet. Of course, it could be that the ATM is unable to connect with the centralized system, and therefore all that this ATM knows is what it last knew, namely that you still only have $40 in your account.
The ATM probably should tell you that it cannot connect with the centralized system and so your balance might be considered outdated or “stale” – just so that you’d know that it might not be showing you the latest and greatest amount in your account. But, you know how computers are, maybe no one thought about this happening and so there’s no provision to alert you that you aren’t seeing the latest that’s contained in the centralized system.
Take a step back and let’s rethink this scenario.
Imagine that there wasn’t a centralized system involved at all. Instead, we opted to completely decentralize the banking systems of the bank.
Each ATM would be expected to let all of the other ATMs know when someone’s bank account has changed. Thus, when you put $60 into the ATM at the bank branch, the ATM there was supposed to then send a message to the other ATMs, such as the one at the grocery store, letting them know that you’ve added $60 to your bank account.
When you went to the ATM at the grocery store on your second visit, it might or it might not have yet gotten an update from the ATM at the bank branch. If it did get the update, you’d see that you made the $60 deposit and your $100 balance. If it did not yet get the update, it would assume you still just have the $40. Perhaps all of the ATM’s are perfectly able to communicate with each other, but it just takes a length of time for the one ATM to communicate to all the others about the latest update.
In a distributed system, it’s important to consider the latency aspects, meaning how long will it take for the distributed members to communicate with each other.
If I told you that with your chosen bank you’d need to wait at least 24 hours before your updates at one branch ATM propagated to all the other ATMs of that bank, you might be distressed about the rather excessive delay. You might be so upset that you’ll switch to another bank that can get things done much faster.
Another way to phrase things is to say that we want to ensure that the data is consistent across the distributed members.
At the time that you made the $60 deposit, for a moment in time only the ATM there knows what you’ve done. Assuming that all the others had earlier been informed you had only $40, none of them yet know that you added $60 more. For that moment in time, we have an inconsistency. It is usually desirable to instead have consistency. You want to go to any ATM, no matter where it is, and see that your $60 deposit is known to all of those other ATMs. You want the distributed system to be consistent with respect to how much your bank account has.
Immediate Or Strong Consistency
If possible, you’d likely want immediate consistency, which sometimes is referred to as strong consistency.
Suppose we somehow had interconnected all the bank’s ATMs with super-duper fast fiber cable and within a split second of your $60 deposit it was communicated to all the others.
From your perspective, it would seem as though it was instantaneous and utterly consistent.
I think we can all agree though that it would still have been momentarily inconsistent, maybe just for a fraction of a second while the updates were occurring, but, meanwhile, admittedly, for practical purposes of you going to another ATM to check your balance, it sure seemed like there was no gap in time.
The principle of “eventual consistency” now can be considered in our story herein about distributed systems.
Assume that we cannot achieve pure instantaneous consistency, and there’s going to be some amount of delay involved in ensuring that all the distributed members are updated. I might scare you by saying that our distributed system could be designed such that it will never fully achieve consistency, meaning that some of those ATM’s aren’t ever going to get updated about your $100 balance.
That’s ugly, I realize, but it could be a possibility.
You might say to me, Lance, I can’t take that, and so please promise that the distributed system has at least eventual consistency.
Inevitably, even if it takes a large delay, eventual consistency is the notion that you want to make sure that consistency is ultimately reached.
Maybe in the first few hours of your making the $60 deposit, half of the other ATMs get updated.
Then, suppose after about ten hours have passed, now 90% of the ATM’s are updated. By the time a 24-hour period has expired, suppose 100% of the ATM’s are updated. In that sense, eventually consistency was achieved.
You might be ecstatic that the eventual consistency was ultimately achieved and the 100% update was made across the board.
Meanwhile, you might be mildly concerned that during the 24-hour period, there was some stale data and the fresh data had not yet entirely propagated. For designing a distributed system, there’s always a difficult trade-off of the latency (delay) time versus the staleness/freshness of the data, and the cost of the system. You ideally want the least delay to ensure the freshest data is available, but this likely comes at a high price in a non-centralized or distributed system.
Here’s a typical semi-formal definition for eventual consistency: Eventual consistency is a type of distributed model approach that informally provides that for any given data item, eventually the accesses to that data item will return the latest updated value.
There is a myriad of ways to implement this notion of “eventual consistency,” and also whether or not the distributed system “guarantees” that the consistency will ultimately be achieved or not.
You also can characterize the distributed system as having strong consistency versus weak consistency. The designer of the distributed system needs to consider how large the distributed system is or will become, such as say having only 50 ATM’s (nodes) or a massive 50,000 ATM’s (nodes).
How scalable does it need to be?
What kind of availability is expected?
How complex can it be?
Autonomous Cars And Consistency
What does this have to do with AI self-driving driverless autonomous cars?
At the Cybernetic AI Self-Driving Car Institute, we are developing AI for self-driving cars, which includes designing and crafting the on-board distributed components of the self-driving car.
An AI self-driving car has tons of computer processors and tons of software components, encompassing aspects that entail the running of the car and the running of the AI, along with the numerous sensors and other devices. It’s a distributed system.
Accordingly, it is important to be concerned about the “consistency” of the data that’s within that distributed system.
For further background about the timing aspects in the distributed system of an AI self-driving car, see my article: https://aitrends.com/selfdrivingcars/cognitive-timing-for-ai-self-driving-cars/
For my overall framework about AI self-driving cars, see: https://aitrends.com/selfdrivingcars/framework-ai-self-driving-driverless-cars-big-picture/
Rather than covering further the distributed system aspects of consistency, I’d like to shift your attention toward another angle on consistency as it relates to AI self-driving cars. This will parlay into the nature of eventual consistency, per my story about banking and ATMs.
The key aspects of the driving task for an AI self-driving car consist of:
- Sensor data collection and interpretation
- Sensor fusion
- Virtual world model updating
- AI action planning
- Car controls commands issuance
The AI self-driving car makes use of various sensors, such as cameras, radar, LIDAR, sonar, and collects data about the world surrounding the self-driving car.
This data needs to be interpreted and transformed for use by the rest of the AI system. It is fed into the sensor fusion portion, which tries to reconcile the multiple ways of sensing the surroundings. The camera and vision processing might spot some aspects, the radar might spot some of those same aspects and also spot other aspects that the camera did not detect, and so on. The results of the sensor fusion are fed into the virtual world model that is being kept updated, reflecting in a virtual way the surroundings.
With the virtual world model, the AI system can try to predict what will happen next.
A car coming toward the self-driving car might be getting ready to turn in front of the self-driving car. If the virtual model suggests that’s what is going to happen, the AI action plan component then would try to devise the action to be taken by the self-driving car. Perhaps the self-driving needs to slow down, or maybe it needs to swerve to avoid the other car.
Once the AI action plan is formulated or updated, the AI system would issue car controls commands, causing the physical mechanisms of the car to turn the wheel, hit the brakes, or get the car to accelerate, as befits whatever action is intended.
While driving down a road, these driving actions are happening in a repeated cycle.
The sensor data is being collected, it is fed into the sensor fusion, which is fed into the virtual world model, which is fed into the AI action planner, which feeds into the car controls commands issuance. This repeats over and over. It is taking place in real-time. And it has to happen fast enough that the self-driving car is properly and safely driving on the roadways.
The data being brought into this repeating cycle is often gradually going to reveal an overall arch of something that is taking place in a more macroscopic way.
If you look at how a teenage novice driver copes with driving, they often are only focused on the moment to moment execution of the driving task. They see what’s directly ahead, they react.
It’s a simple monkey-see, monkey-do, kind of action. A more seasoned driver is able to deal with the moment to moment elements of driving, and also has an ability to anticipate a longer term viewpoint too. The seasoned driver might be watching traffic way up ahead, and not just looking at the bumper of the car directly in front of their car.
For insights about defensive driving and what AI self-driving cars need to do, see my article: https://aitrends.com/selfdrivingcars/art-defensive-driving-key-self-driving-car-success/
For my article about the human foibles of driving and what an AI self-driving car needs to do, see: https://aitrends.com/selfdrivingcars/ten-human-driving-foibles-self-driving-car-deep-learning-counter-tactics/
Confusion Due To Inconsistency
A novice driver tends to be confused by inconsistency.
Suppose the car directly ahead of them is braking, but the car to their right is not. Shouldn’t both of those cars be braking?
And, if they are both braking, the novice figures maybe they should hit the brakes too. But, if only one of them is braking, maybe they shouldn’t be braking.
Or, maybe they should.
The narrowness of the novice’s viewpoint of the traffic and roadway makes it difficult to cope with what seems to be inconsistent behavior (or, if we consider the behavior as something perceived by your senses, we might then say that the data seems to be inconsistent).
Stale data becomes relevant here too.
I was sitting in a car of a novice teenage driver that looked over his shoulder to see if it would be safe to make a lane change. The teenager didn’t see any car in the next lane and so mentally decided it would be OK to make the lane change. Upon the teenager’s gaze coming back to looking forward, he momentarily become attentive to the car ahead that was tapping its brakes.
The teenager then decided that he should quickly make the lane change, avoiding possibly riding up upon the now braking car ahead. Unfortunately, in the few seconds of his looking forward, a car from a third lane had come into the lane that he wanted to get into, and now was sitting right where he would make his lane change.
The data he had in his mind was stale.
It no longer reflected the reality of the situation around him. Without realizing that he needed to refresh the data, he would have for sure made the lane change and likely cut-off the other car. Worse, his car and the other car could have hit each other. I spoke up just as he started to make motions to switch lanes, and gently dissuaded him (it was a gentle caution, since I didn’t want to cause a panic and have him make some dire move!).
Let’s use an even larger scope example of how the consistency or inconsistency of data can emerge over time.
Emergent Consistency Aspects Over Time
You are on the freeway, driving along at full speed.
At first, traffic seems wide open.
You then notice that there is intermittent braking taking place in the traffic up ahead. It’s sporadic. Next, the braking becomes more persistent and widespread. Traffic begins to slow down. The slowing progresses to becoming slower and slower. The traffic then becomes bumper to bumper. It’s now stop and go traffic. Overall, traffic is now moving at a crawl.
I’m sure you’ve experienced this kind of traffic before.
Pretty typical, especially for a morning or evening commute.
What do you make of this traffic situation?
If you are a novice driver, perhaps you are not thinking beyond the fact that the traffic is moving at a crawl.
A more seasoned driver is likely to begin speculating about what is causing the slowing of traffic.
Is the roadway and number of lanes not sufficiently large enough for the volume of traffic?
Is there a bend in the road ahead and it has caused drivers to slow down to be cautious because they cannot see what’s ahead?
Is there perhaps debris on the freeway and cars are slowing to avoid hitting the debris?
Suppose I told you that you could now just barely see some flashing lights up ahead. What would you now guess is happening?
You’d likely be thinking that flashing lights might mean a police car, or a fire truck, or an ambulance. Any of those on the freeway and with their flashing lights on probably suggests an accident up ahead. You can’t say for sure that’s what is occurring, but it’s a reasonable guess.
Next, I tell you that you can now see some flares and red cones on the freeway up ahead.
You are now probably betting that indeed there must have been a car accident. You also are guessing that it must have happened some time ago, in that if it had just happened there wouldn’t yet be cones and flares. The police or other workers that showed up must have put down the flares and cones. All of that would have taken time.
You then see that a fire truck is parked on the freeway, straddling several lanes. At this juncture, without even being able to see beyond the firetruck, you are pretty sure there’s a car accident scene. It makes sense, given the clues so far.
For my article about accident scene traversal and AI self-driving cars, see: https://aitrends.com/selfdrivingcars/accident-scene-traversal-self-driving-cars/
Let’s now revisit what has taken place in this example.
The initial data about the traffic was that it was flowing unimpeded.
Then, the data was that the traffic was starting to use their brakes. Some cars were still going fast, some were slowing down.
In a sense, you are getting data that seems “inconsistent” and you are seeking to make it become “consistent” so that you can put together a cohesive indication of what is taking place.
Part of the macroscopic overarching aspect of the AI system in an AI self-driving car is that it should be dealing with this kind of eventual consistency.
There is a sprinkling of data that at first suggests an inconsistency. From this, there becomes a gradual consistency as the data is further gathered and time progresses. At any moment in time, the AI system can be in a posture of not being sure of what is going to happen next, but it can be constructing a prediction based on what has occurred so far.
The eventual consistency might gradually be achieved, such as in this scenario that led to the realization that a car accident was up ahead. Or, the eventual consistency might not be resolved. I’m sure you’ve had times that the traffic slowed to a crawl and you thought for sure there must be an accident up ahead, and then once you got further ahead there seemed to be no rhyme or reason why the traffic had slowed.
For the AI developer perspective on AI self-driving cars, see my article: https://aitrends.com/ai-insider/egocentric-design-and-ai-self-driving-cars/
For the role of idealism in AI development mindsets, see my article: https://aitrends.com/selfdrivingcars/idealism-and-ai-self-driving-cars/
Some AI developers have a mindset that they assume that the AI of the self-driving car will exist in a perfect world of having all needed information and the right information, and the fresh information, whenever needed.
Even a novice teenage driver knows that to not be the case. Driving involves dealing with imperfect information.
Decisions must be made based on sketchy data. Patterns that might eventually arrive at a state of consistency, might not. These are important aspects that any true AI self-driving car is going to need to cope with.
Eventually, for sure.
Sooner, rather than later.
Copyright 2019 Dr. Lance Eliot
This content is originally posted on AI Trends.
[Ed. Note: For reader’s interested in Dr. Eliot’s ongoing business analyses about the advent of self-driving cars, see his online Forbes column: https://forbes.com/sites/lanceeliot/]