Why this blog

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:

levels_of_verification


3 thoughts on “Why this blog

  1. 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

    Like

  2. 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.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s