16 www.techbriefs.com Tech Briefs, August 2017

transformations allowed are applied,then the conclusion reached at the end— the theorem — must be true.

Formal methods for engineeringcomputer systems work in much thesame way. In computer science, formalmethods really kicked off — on a theo-retical basis — in the late 1960s andearly ‘70s, when widespread use of com-puting was still in its infancy. Theo -retical mathematicians were observingcomputer programming — still relative-ly simple at the time — and saying,“That’s a mathematical structure; I canapply set theory to that.”

Tony Hoare is generally credited withintroducing formal methods to comput-er science with his invention of Hoarelogic. This and similar formal methodswork much like algebra. They evenmake use of algebraic laws, like the asso-ciative, commutative, and distributiveproperties. If you apply the same opera-tions to both sides of the equal sign,then the equation remains equal.

Let’s say you want to prove that aspecific output of your system nevergoes above a certain value. Using for-mal methods, you would apply yourchosen set of rules to prove that yourassumption — your requirement — istrue. In the end, if you’ve applied youralgorithms correctly, and if you findthat indeed, your selected outputnever exceeds that specified value,then, as in a Euclidean proof, there isno question your theorem is true.You’re absolutely certain. You’veproven beyond a doubt that your sys-tem meets that requirement.

In contrast, if you were to apply a rep-resentative set of inputs to your systemto test your assumption empirically, youcould never really be sure your assump-tion was true, unless your set of testcases exercised all possiblecombinations of input val-ues and stored states thataffect the selected output —a daunting and exponentialtask in today’s embeddedsoftware environment.

Formal Methods forEngineeringApplications

Formal methods didn’tgain much traction withindustry until the 1990s.Before then, computersand computer programswere relatively simple, while

formal methods were primitive and dif-ficult to apply. Testing remained themost efficient means of system verifica-tion. Then, programming errors begangetting companies into serious trouble.

Not long after the Therac-25 catastro-phe, disaster struck AT&T’s global long-distance phone network. On January 15,1990, a bug in a new release of switchingsoftware caused a cascade of failures thatbrought down the entire network formore than nine hours. By the time thecompany’s engineers had resolved theproblem — by reloading the previoussoftware release — AT&T had lost morethan $60 million in unconnected calls.Plus, they’d suffered a severe blow totheir reputation, especially amongst cus-tomers whose businesses depended onreliable long-distance service.

Four years later, a bug was discoveredin the floating-point arithmetic circuitryof Intel’s highly publicized Pentiumprocessor. This error caused inaccura-cies when the chip divided floating-pointnumbers within a specific range. Intel’sinitial offer — to replace the chips onlyfor customers who could prove theyneeded high accuracy — met with suchoutrage that the company was eventuallyforced to recall the earliest versions.Ultimately, the Pentium FDIV bug costIntel some $475 million.

The Therac-25, the AT&T switchingcontrol software, and the Intel Pentiumchip were all tested extensively. Still, thattesting failed to find the catastrophicbugs in those systems. Today, due in largepart to the Pentium bug, formal methodsverification is now a standard practice atIntel, and is used routinely by other man-ufacturers to verify IC chip designs. Yetsoftware developers lag far behind hard-ware makers in the use of formal meth-ods for embedded system verification.

This discrepancy is due primarily tothe difference between IC logic andmodern software logic. The logic in aCPU reduces to arrays of logic gates:ANDs, NANDs, ORs, etc. It’s all Boolean.The formal methods engines used forBoolean logic, such as satisfiabilitysolvers (SAT solvers), are now very wellunderstood (thanks again to the Pen -tium bug, and to companies who pickedup the ball and ran with it). Formal ver-ification of ICs requires very fast com-puters, but only because the logic arraysare so vast.

Software is a whole different problem.Modern software logic is more compli-cated than IC logic. It requires moresophisticated mathematics. The solversused in formal methods verification ofsoftware, known as satisfiability modulotheories SMT solvers, add mathematicalconstructs beyond Boolean logic.

SMT solvers have taken longer tomature; in fact, they’re still evolving.For now, it is quite difficult to applyformal methods to the full source codeof large-scale embedded applications.Convert ing large, complex sourcefiles, like a flight-control program,into formal methods language is still adaunting, arduous, and extremelytime-consuming task. But that doesn’tmake formal methods software verifi-cation impossible.

To apply formal methods to a largesoftware program today, you need todo one of two things. You can applythem to small portions of the program;critical parts that must work withoutfail, for example. Or you can applythem to an abstraction of the actualimplementation. Model-based design isjust such an abstraction. It simplifiesthe representation of the system andbreaks it into interconnected blocks.

This abstraction, in turn,simplifies both the task oftranslating the designinto formal methods lan-guage, and the task ofquerying the system.

Recent breakthroughs,as well as complete cover-age of the design, nowmake this second ap -proach the preferred onefor formal verification ofembedded systems. Butbefore this approach is dis-cussed further, let’s lookmore closely at the reasonsfor applying it.

Formal methods verification tools find “odd” cases that testing often misses— cases that take many time steps to trigger.

ENGINEERING EMBEDDED SYSTEMS

Cov ToC + – �

�

AIntro

18 www.techbriefs.com Tech Briefs, August 2017

The Urgent Need for FormalMethods

The amount of software in cyber-physical embedded systems continuesto grow. Systems like automobiles,which were purely mechanical 30 or 40years ago, are now bristling with proces-sors running millions of lines of code.More and more of that code is mission-critical and safety-critical. Embeddedprograms are getting so big, they’rebecoming too difficult to test.

Traditional testing methods involv-ing test cases and coverage — methodsthat worked fine 20 or 30 years ago onsimpler systems — don’t really workanymore. The sheer volume and com-plexity of today’s embedded softwaremake testing a losing proposition. Itkeeps getting harder and harder toprove that nothing disastrous will gowrong.

Lack of confidence in testing is begin-ning to impede innovation. Take theintegration of self-driving cars with com-puter-controlled intersections. Scientistsclaim this concept would eventuallyeliminate the need for traffic lights, easeurban road congestion, and save mil-lions of lives. Unfortunately, some engi-neers at the Embedded SoftwareIntegrity for Automotive Conference inDetroit last year said that while they havethe capability to build such a system,they literally cannot solve the problemof how to verify it to a high enough levelof confidence. They wouldn’t be able totrust it; it would just be too great a liabil-ity. In other words, engineering ideasand design capacities are outpacing theability to test the software that controlsthem.

Why the Time is Right forFormal Methods

Formal methods represent a big shiftaway from how most systems are beingverified today. Making that shift willrequire a significant expenditure, andfor now, it’s tough to make an economicjustification for it. Could you simplyincrease testing and still spend less? Itwould be hard to argue with that. It’s dif-ficult to calculate ROI until a catastro-phe occurs. On the other hand, compa-nies that doggedly continue with tradi-tional testing will risk getting leftbehind. Organizations like NASA,Lockheed Martin, and Honeywell aregradually making the shift to formalmethods. Those who delay could findthemselves struggling to catch up.

There is no real alternative in sight.Traditional testing is simply not a viablemethod for verification of tomorrow’scomplex embedded systems. Companiesneed to start looking at formal methodson small projects or parts of projects,and begin charting their migration toformal methods verification. Fortu -nately, three major breakthroughs aremaking it far easier to adopt formalmethods today.

The first of these breakthroughs isan exponential improvement in SATand SMT solvers and theorem provers.These tools are now thousands of timesfaster than they were just a few yearsago. New solvers and theorem provers,like Microsoft’s Z3, amalgamate differ-ent types of solvers to solve differenttypes of problems. They’re bringingtogether the best research fromaround the world and putting it atusers’ fingertips.

Second, dramatic reductions in thecost of distributed computing now letus throw much more computing powerat a problem for much less money. Asa result, a problem that may havetaken an SMT solver eight minutes tosolve in 2012 takes only about two sec-onds today.

And finally, the more widespreadadoption of model-based design ismaking it easier to apply formal meth-ods to a wider range of problems. Thismarket has given rise to the develop-ment of a growing number of formalmethods verification tools that are built for use with model-baseddesign applications like MathWorks’Simulink.

The Advantages of Model-Based Design

Without the new tools just mentioned,translating a Simulink model into solverlanguage would be slow, tedious work,and the result would likely not be veryrobust. Plus, solver output tends to bedifficult to interpret for someone with-out a practiced eye. With new tools, onthe other hand, the process of transla-tion is automated and accelerated, whileinterpretation is greatly simplified andfar more intuitive.

One of the biggest advantages of for-mal methods verification tools is thatthey find those “odd” cases that testingoften misses — cases that take manytime steps to trigger. These are casesthat testers wouldn’t think of that causedisasters like those mentioned earlier.

That’s because an SMT solver doesn’tformulate test cases or reason aboutwhether something is reasonable totest. It simply solves the equation. Itexamines everything that could affectthe output.

Because they solve equations, formalmethods verification tools provide bet-ter coverage than even automated testcase generation. Test cases generated bya modeling tool may test every path, butthey won’t cover every condition. Formalmethods verification tools offer com-plete coverage because they convert themodel into a single (albeit enormous)equation and solve the equation foreach requirement.

Formal methods may also facilitate anew model-based design process calledcorrect by construction. To use thisprocess, you first model a small por-tion of the system, and then verify itusing formal methods. It is then cor-rected and re-verified until you’re100% certain that part of the systemfunctions perfectly. Then you add a bitmore to the model and run a completeverification again. Since you’ve alreadyverified your baseline model, youknow that any errors you find will be inthe latest edition. You then correct, re-verify, and keep repeating the processuntil your design is complete. Correctby construction should result in sys-tems that are better designed andmore reliable.

Finally, by querying their models withformal methods tools, engineers gaingreater understanding of their designs.Greater understanding will give themgreater confidence in their currentdesign, and — in terms of lessonslearned — a stronger foundation tobuild on in future projects.

ConclusionState-of-the-art embedded systems

have become too big and too complexto be reliably verified using traditionaltesting methods. Traditional testinghas simply become too risky from a lia-bility standpoint. The only viable alter-native in sight is formal methods verifi-cation. Many forward-thinking compa-nies have already begun making theshift to formal verification. It is wisefor others to do the same, if they wishto remain competitive.

This article was written by Dean Tsaltas,CTO of QRA Corp., Halifax, Nova Scotia,Canada. For more information, visithttp://info.hotims.com/65854-121.

ENGINEERING EMBEDDED SYSTEMS

Cov ToC + – �

�

AIntro