406 research outputs found
Sentencia del Segundo Tribunal Ambiental en el caso “Pascua Lama” Sentencia Rol R-6-2013, de 3 de Marzo de 2014
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
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
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
- …