Advances in automated theorem provers over the last decade have led to a renaissance in software tools that compile problems of correctness to problems over logic formula. In this talk, I will review progress in automated theorem provers, such as Z3 from Microsoft Research, and consider a variety of program correctness tools that build upon Z3, such as automated test generators, automated safety/termination checkers, as well as interactive functional verifiers. I'll then describe a number of new projects that make use of the "correctness via compilation to logic" approach, including the design of new programming languages, ensuring the security of data centers, and safely programming gesture recognizers such as Kinect.
Correct design, and system-level dependability prediction of highly-integrated systems demand the collocation of requirements and architectural artifacts within an integrated development environment. Hybrid systems, having dependencies and extensive interactions between their control portion and their environment, further intensify this need. AADL is a model-based engineering language for the architectural design and analysis of embedded control systems. Core AADL has been extended with a mechanism for discrete behavioral modeling and analysis of control systems, but not for the continuous behavior of the physical environment. In this paper, we introduce a lightweight language extension to AADL called the Hybrid Annex for continuous-time modeling, fulfilling the need for integrated modeling of the computing system along with its physical environment in their respective domains. The Isolette system described in the FAA Requirement Engineering Management Handbook is used to illustrate continuous behavior modeling with the proposed Hybrid Annex.
Ada 95, aka Ada9X at the time because we didn't know when we would be done, was a labor of love for most of us. A spectacular team was assembled from all over the world. I had the distinct pleasure and honor of being the Department of Defense Ada 9X Project Manager. The lessons I learned and the experience I gained allowed me to do many other things after Ada 95 was completed. I ran an Air Force space technology laboratory. I was responsible for building military satellites and launching them from the Cape. Currently, I am responsible for developing and operating the first purpose-built commercial spaceport. Looking back, the common thread through all of these endeavors is innovation, dedication, strong team work, and a passion for the job at hand. That can do spirit and boundless energy is a must for success and I have been fortunate to work on unprecedented projects with colleagues who possessed these qualities. Anecdotes from the Ada9X Project to today's emerging commercial space industry will be provided from my experiences and observations.
Specification based on Floyd-Hoare logic, using pre- and post-conditions, is common in languages aimed at high integrity software. Such pre/postcondition specifications are geared towards verification of code. While this specification technique has proven quite successful in the past 40 years, it has limitations when applied to API specification, particularly specification of generic interfaces. API-oriented design and genericity is of particular importance in modern large-scale software development. In this situation, algebraic specification techniques have a significant advantage. Unlike pre/post-based specification, which deals with the inputs and outputs of one operation at a time, algebraic specification deals with the relationships between the different operations in an API, which is needed in the specification of generic APIs.
Arguments about the safety, security, and correctness of a complex system are often made in the form of an assurance case. An assurance case is a structured argument, often represented with a graphical interface, that presents and supports claims about a system's behavior. The argument may combine different kinds of evidence to justify its top level claim. While assurance cases deliver some level of guarantee of a system's correctness, they lack the rigor that proofs from formal methods typically provide. Furthermore, changes in the structure of a model during development may result in inconsistencies between a design and its assurance case. Our solution is a framework for automatically generating assurance cases based on 1) a system model specified in an architectural design language, 2) a set of logical rules expressed in a domain specific language that we have developed, and 3) the results of other formal analyses that have been run on the model. We argue that the rigor of these automatically generated assurance cases exceeds those of traditional assurance case arguments because of their more formal logical foundation and direct connection to the architectural model.
