Keynote Lectures

Abstract
"Big design up front is dumb. Doing no design up front is even dumber." This quote epitomises what I've seen during our journey from "big design up front" in the 20th century, to "emergent design" and "evolutionary architecture" in the 21st. In their desire to become "agile", many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it's a misinterpretation and misapplication of the agile manifesto.
As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can't be communicated, assessed, or reviewed. The same is true of long-lived documentation, which is typically a collection of disconnected diagrams that are out of sync, and out of date. Modelling can help resolve many of these problems, but that's a tough thing to sell to mainstream developer audiences these days - teams are either not aware of modelling, or they associate it with bad experiences using complicated CASE tools from the past. Join me for a discussion about the lost art of software architecture modelling, and my experiences of how I've reintroduced it to the agile generation.

Abstract
Cyber-Physical Systems (CPS) are increasingly incorporating Learning-Enabled Components (LEC) to implement complex functions. By LEC we mean a component (typically, but not exclusively, implemented in software) that is realized with the help of data-driven techniques, like machine learning. For example, an LEC in an autonomous car can implement a lane follower function such that the developer trains an appropriate convolutional neural network with a stream of images of the road as input and the observed actions of a human driver as output. For high-consequence systems the challenge is to prove that the resulting system is safe: it does no harm, and it is ‘live’: it is functional. Safety is perhaps the foremost problem in autonomous vehicles, especially for ones that operate in a less-regulated environment, like the road network. The traditional approach for proving the safety of systems is based on extensively documented but often informal arguments – that are very hard to apply to CPS with LEC. The talk will focus on a current project that aims at changing this paradigm by introducing (1) formal verification techniques whenever possible (including proving properties of the ‘learned’ component), (2) monitoring technology for assurance to indicate when the LEC is not performing well, and (3) formalizing the safety case argumentation process so that it can be dynamically evaluated. The application target is autonomous vehicles. The goal is to construct a model-based engineering process and a supporting model-based toolchain that can be used for the engineering and systematic assurance of CPS with LECs.

Abstract
In a model-based engineering approach, many aspects of the model elements need to be characterized or specified through physical quantities. Traditionally, many modelling languages and frameworks have used simple conventions for naming quantities and associating basic numeric types (e.g., real, float, integer) to represent their values. Often the types are enhanced with some kind of annotation to convey applicable measurement units, and, sometimes, their quantity dimension. This can work reasonably well in smaller, single discipline, single tooling environments. However, multi-disciplinary, highly iterative engineering of larger, complex systems, with interfaces across many engineering organizations, demands a more sophisticated approach. The simple approach supported by manual checks quickly reaches its limits. A rigorous semantic approach with systematic checks by machine is needed to prevent the multitude of serious errors that can – and regularly do – arise from mismatches or misinterpretations of quantities and their values. Models themselves, tools, transformations, execution results, etc. are all prone to such mistakes. I daresay most of us have suffered one time or another from such problems.

The keynote will present the formal approach taken to develop an extensible model library for version 2 of the OMG Systems Modeling Language (SysML), and compares it with other formal approaches. The SysML v2 semantic model or ontology elaborates on the earlier informative QUDV (Quantities, Units, Dimensions and Values) package of SysML v1. It goes beyond scalar quantities, measurement units and simple scales, by adding support for tensor and vector quantities, integration with coordinate system definition and transformation, as well as representation of free and bound vector spaces. It allows to perform automated quantity value conversion (for a change of unit or scale) and dimensional analysis of expressions that involve quantities. The SysML v2 concrete textual syntax supports a very natural reading of quantity values, e.g., mass = 24 [kg]. The chosen approach uses the terminology of the International Vocabulary of Metrology (see https://jcgm.bipm.org/vim/en/index.html) as a basis. Apart from the semantic model, the library comprises packages that predefine all quantities and units standardized in the ISO/IEC 80000:2019 series (International System of Quantities and SI) as well as a package that captures the US Customary Units, and their conversion factors to SI, as specified in NIST SP 811. A number of practical SysML v2 examples will be shown.