Welcome to the Foretellix blog. Here is a short introduction:
My name is Yoav Hollander. I have been doing verification practically forever [1] (e.g. I created the e verification language).
By “verification” I mean here roughly “the process of finding bugs (or unintended consequences) in engineered systems before they annoy a customer / destroy a project / kill somebody”.
Foretellix is trying to investigate how dynamic, constrained-random, coverage-driven verification (let’s call it “CDV” – this is the bread-and-butter of hardware verification) can be extended for verifying complex socio-technical systems.[2]
Just how Foretellix will go about achieving this is still work-in-progress (motto: “So deep in stealth mode even we are not quite sure what we are doing”).
I have been investigating this field (“big-system-verification”) for a while now. A few weeks ago I decided to attend the Autonomous Vehicle Test & Development Symposium in Stuttgart. I sent my trip report to a whole bunch of people, and was pleasantly surprised by the thoughtful feedback I got in replies (some of it summarized here).
So I decided to write this blog, as a tool for clarifying my thoughts, entertaining my readers, and (mainly) for getting feedback. See also the topics page and the terminology page.
So:
- Please comment directly in the blog. This is supposed to be very interdisciplinary, open and friendly. Feel free to go in any related direction.
- If you want to contact me privately, just email yoav.hollander at gmail.com
- Please forward this blog to anybody else who might be interested. We may also have some guest posts from time to time.
- I will not be collecting any email addresses, sending any requests, posting any ads or anything like that
Have fun – hope you’ll enjoy the conversation. Remember: verification is really tough, but really important.
And it can be fun. For now, let’s keep the tone light (until I get serious corporate lawyers who will request the removal of all jokes and mourn the fact that web archives are forever). Let me end this post with the obligatory Nathaniel Borenstein quote:
“The most likely way for the world to be destroyed, most experts agree, is by accident. That’s where we come in; we’re computer professionals. We cause accidents”
Notes
[1] Since the early bronze age.
[2] Here is some (old’ish) background on what Foretellix is trying to do (e.g. look at the FAQ).
The picture below shows the audacious scale of what this blog is about:
Hi Yoav!
This is very interesting! I’m looking forward to finding out how you randomly constrain the socio portion of the simulation. I assume the sims are hoping to anticipate human error and avoid it?
Hi Hamilton
Right, in the cases where the Device Under Test (or Verification Environment) contains people, one needs to somehow simulate them and randomize their behavior so as to find bugs.
There are actually some common suggestions of how to create a simple model of the decision-making process of humans (or human-like agents, like corporations and committees). One of the most popular is BDI (see https://en.wikipedia.org/wiki/Belief%E2%80%93desire%E2%80%93intention_software_model ), where you model each such agent (e.g. your simulated pilot, your simulated air traffic controller) as an object with a list of beliefs, desires and intentions.
Each agent then has a loop of “update beliefs, update plan to to achieve desires, repeat”, and you can insert random errors (in new beliefs, in choosing the plan, etc.).
This is, of course, just one possible meaning of “how to simulate people”. As in hardware verification, you model the aspects you care about, and keep your fingers crossed ;-).
Yoav
Yoav, I am looking forward to following, and as time permits, contributing to this discussion.
Regarding verification being “the process of finding bugs (or unintended consequences) in engineered systems before they annoy a customer / destroy a project / kill somebody,” as a stickler for precision I think “bugs” must be defined. While actively engaged in this field I employed the following definition, almost as my mission statement, for verification: Demonstrate the intent of a design is preserved in its implementation. As a consequence, a bug would be intent that was not preserved.
Dear Yoav, your name popped up when I was reading articles from Philip Koopman. I’m following Philip since 2008 when I had an almost fatal accident because of a software bug in a Volkswagen Scirocco with dynamic damping control. I just wrote an article about software bugs in cars (and busses and also bridges) for a Belgium Blog called Doorbraak – http://www.doorbraak.be – who are the only online newspaper wanting to publish about this topic. My profession is medical technician (in Europe it’s the same level as a university) but in 1998 I started an online motorbike magazine (besides my job as a medical technician) and in 2008 an online car magazine. It seems that I’m the only Dutch car-journalist who writes about software bugs in cars the other Car-journalists believe it exists only in Tesla’s (Tesla bashing is very popular in Holland) and don’t believe that it can kill you when you’re at the wrong time at the wrong place. Why are software bugs in cars so unpopular in the media? Is it because of the money? Greeting Daniël van der Keur/The Netherlands