Source Code Verification for Embedded Systems using Prolog

System relevant embedded software needs to be reliable and, therefore, well tested, especially for aerospace systems. A common technique to verify programs is the analysis of their abstract syntax tree (AST). Tree structures can be elegantly analyzed with the logic programming language Prolog. Moreover, Prolog offers further advantages for a thorough analysis: On the one hand, it natively provides versatile options to efficiently process tree or graph data structures. On the other hand, Prolog's non-determinism and backtracking eases tests of different variations of the program flow without big effort. A rule-based approach with Prolog allows to characterize the verification goals in a concise and declarative way. In this paper, we describe our approach to verify the source code of a flash file system with the help of Prolog. The flash file system is written in C++ and has been developed particularly for the use in satellites. We transform a given abstract syntax tree of C++ source code into Prolog facts and derive the call graph and the execution sequence (tree), which then are further tested against verification goals. The different program flow branching due to control structures is derived by backtracking as subtrees of the full execution sequence. Finally, these subtrees are verified in Prolog. We illustrate our approach with a case study, where we search for incorrect applications of semaphores in embedded software using the real-time operating system RODOS. We rely on computation tree logic (CTL) and have designed an embedded domain specific language (DSL) in Prolog to express the verification goals.Comment: In Proceedings WLP'15/'16/WFLP'16, arXiv:1701.0014

A life cycle for creating an uncomplicated software

Modern software development life cycle models tend to be less formal and less rigid then Waterfall based models of the past. However, creating software without following even the most basic of plans often results in poorly structured, faulty, and hard to maintain software. This paper proposes a practical development model for the purpose for software development. Following some sort of plan produces better code than no plan at all. This model has been shown to be successful even with inexperienced developers

Model-Based Framework for On-Board-Software

Satellites carry different payloads, but the basic design in hard- and software is generally similar for small satellites. For example, they all receive telecommands, distribute them and generate telemetry packets. Reusing existing components is desirable, especially with limited time and financial budgets. This is where the Corfu comes in, which we present in this work. Corfu is a software framework for safety-critical on-board software. It follows a model-based approach. Developers formally define the structure of the software. The software design is app-centric, i.e. on-board software in Corfu is a composition of apps. Apps define a clear communication interface using a publish/-subscribe principle. This allows on-board software to connect apps among each other. Developers can use and connect apps in different on-board software and even on different missions. This encourages reusability. Based on the information of software definition, Corfu applies two tasks: formal verification of the software structure and generation of source code. In the verification step, Corfu examines the timing properties across all apps that are included into the software. Having a formal definition that is used for both static analysis and code generation, makes in possible to identify structural problems early. The generation process creates code that it can derive from the software specification. This includes communication handling, such as subscribing to topics, distributing telecommands and collecting telemetry. In addition, the generated code also covers thread handling. The result of the generation process is a collection of classes. Most of those classes are abstract, which include abstract methods that the developer fills with mission-specific code. Developers do this by inheriting from those abstract classes and overriding all the abstract methods by carrying out the desired behavior. Developers can focus on implementing the mission relevant code. The software specification defines the communication interface between space and ground as well; therefore, it is sensible to use the same definition for the ground software. Corfu comes with a library for ground software, which parses the configuration file and makes it available to the developer. It also comes with a link interface towards the space segment. Based on the library, Corfu provides a ready-to-use generic ground software with a graphical user interface printing telemetry data and for sending telemetry — according to the software definition. Beyond formal verification of the software definition, Corfu comes with an elaborated testing framework, which provides unit and integration tests to the developers. By generating test-specific classes, Corfu gives developers access to internal software parts to allow more accurate unit testing. By automatically sending telecommands and evaluating telemetry data, developers accomplish integration tests of the full on-board software stack. Corfu already comes with applications and concepts that are common to general on-board software, such as publish/subscribe communication between applications, anomaly and event handling, telecommand distribution among applications, telemetry collection, housekeeper, etc

Designing uncomplicated software

The Agile Manifesto prescribes less focus on tools and processes, and more focus on human interactions. This is avery important and powerful concept; however, many development organizations have interpreted it in terms ofno procedures and no processes. This is understandable as many activities, such as the design workflow, are thanklessand laborious. When a proper design is missing, the resulting source code may become overly complicated anddifficult to maintain. The software design does not have to be arduous as this workflow can be done without painthrough an adaptation called Responsibility-Driven Design. This adaptation assigns personalities to the internalcomponents of the software to humanize the operation. The new design workflow is completely compatible withagile concepts such as customer interaction, and produces a credible candidate architecture ultimately resulting inthe creation of a less complicated software.El Manifiesto Ágil prescribe disminuir el foco en las herramientas y procesos para centrarlo en las interacciones humanas. Este es un concepto muy importante y potente; sin embargo, muchos equipos de desarrollo lo han traducido en términos de no procedimientos y no procesos. Esto es comprensible ya que muchas actividades, entre ellas el flujo de trabajo del diseño, son ingratas y laboriosas. Cuando no se realiza un diseño apropiado, el resultado puede ser un código demasiado complejo y difícil de mantener. El diseño de un software no tiene que ser arduo y el flujo de trabajo puede aliviarse con una adaptación denominada “diseño conducido por la responsabilidad” (Responsibility-Driven Design). Esta adaptación asigna personalidades a los componentes internos del software para humanizar la tarea. El nuevo flujo de diseño es completamente compatible con los conceptos de agilidad, como la interacción con el cliente, y produce una arquitectura candidata con credibilidad que resultará en la creación de un software no complicado

Metrics to understand future maintenance effort required of a complicated source code

An enduring engineering problem is the creation of a source code too complicated for humans to review and understand. A consequence of a complicated source code is that it requires more effort to be implemented and maintained. Exacerbating the problem is a lack of a proper understanding of exactly what the words “complicated” and “complex” mean, as the definitions of these words are often misconstrued. Some systems are indeed inherently complex, but this does not mean they must be complicated. In our research, several opensource projects were evaluated using software metrics to map the complicatedness of a source code with the ongoing effort to sustain the project. The results of our research show that a relationship exists between a complicated source code and the maintenance effort. It is clear that adhering to proper coding practices and avoiding a complicated code can result in a much more manageable future maintenance effort.Un problema de ingeniería duradero es la creación de código fuente demasiado complicado para que los humanos lo revisen y comprendan. Una consecuencia del código fuente complicado es que requiere más esfuerzo para implementar y mantener. Lo que exacerba el problema es la falta de una comprensión adecuada de lo que significan exactamente las palabras “complicado” y “complejo”, ya que estas definiciones a menudo se interpretan mal. Algunos sistemas son realmente intrínsecamente complejos, pero esto no significa que deban ser complicados. En nuestra investigación, se evaluaron varios proyectos de código abierto utilizando métricas de software para mapear la complejidad del código fuente con el esfuerzo continuo para mantener el proyecto. Los resultados de nuestra investigación muestran que existe una relación entre el código fuente complicado y el esfuerzo de mantenimiento. Está claro que adherirse a las prácticas de codificación adecuadas y evitar el código complicado puede resultar en un esfuerzo de mantenimiento futuro mucho más manejable