Registro  
Login

Análisis Estático de Código

Desarrollo de Embedded Software


Pruebas de Software y Sistemas

Pruebas de Interfaz Gráfica GUI
Soporte a la Certificación DO-178/254

Soporte a la Certificación ISO-26262

Diseño y Verificación de SoCs y FPGAs

Formación en Certificación Aeronáutica

Formación en Certificación Ferroviaria

Formación en Certificación Automoción

Formación en Ingeniería de Requisitos

Formación en Ingeniería de Desarrollo

Formación en Ingeniería de Pruebas

:
The Vector Test Solution - An integrated test approach along the V-Cycle (combination of CANoe, vTestStudio, VT System, VectorCAST)
There are a lot of testing suites focused on unit testing or getting coverage of any kind of test cases, but there are very few testing suites that cover the full range of testing.

In the presentation, we will describe the Vector approach, that includes Test Design, Test Simulation, Test Execution and Test Reporting, ranging from unit testing, SW Integration Testing, HW/SW Integration Testing and System Testing. The solution, composed by SW and HW packages, includes the possibility to simulate the behaviour of the system (using Matlab/Simulink or Labview models), the behaviour of the external sub-systems or interact with simulated external sub-systems (analog & digital I/O, communication interfaces (RS-232, RS-488, Ethernet, FlexRay, CAN, etc.) or interact with real external sub-systems.
Daniel Haas
Christian Hümbert
Finding the Worst-Case Execution scenario (WCET) on multi-more processors
Violating timing constraints on embedded applications can have severe consequences for the functional behavior of the application. A malfunctioning system can cause unreasonable risk to life and property and must be avoided.

Traditional approaches like dynamic end-to-end measurements are expensive, the test-end criterion is not clear and cannot provide worst-case guarantees.
While we propose for the timing predictable (single-core) processors a pure static program analysis approach (using AbsInt's aiT technology) for the high-end multi-core systems we recommend to use TimeWeaver, an Hybrid WCET analyzer that combines sophisticated static program analysis techniques (like the worst-case path analysis) with non-intrusive tracing.

TimeWeaver reads in the fully linked ELF executables, a list of task/functions entry points and program flow traces (like PowerPC NEXUS BTM/BHM traces) produced non-intrusively via trace units on the modern embedded processors. It extrapolates the maximum instruction timings and finds a worst-case execution scenario from the defined task entry to any possible end point taking also into account effects from multi-core interferences. TimeWeavers WCET result can be used for timing verification or optimization (i.e. identify timing bottlenecks) in the considered code. An automatic tool qualification according to ISO 26262, DO-178B/C, IEC-61508 is possible.

More details can be found on: http://www.absint.com/timeweaver
Miguel Miranda
Image Based Testing: Validating text using OCR Technology
Sometimes is difficut to validate GUI objects, specially when we have images, infographic symbols or embedded text on images. You need an advanced object recognition functionality in order to be able to automatize the testing.

Squish has improved those techniques and offer a really advanced method for object recognition and text extraction from images.

There will be some examples of usage of that technique and how to build test cases with this capability.

More details can be found on:
https://www.froglogic.com/news/squish-gui-tester-6-4-release-with-cutting-edge-object-recognition-features/
Closing the gap between Requirements and Testing for Embedded Systems
In Embedded Systems, specially for safety critical applications, one of the first things is to do is a Safety Assessment to evaluate the potential risks. To mitigate those risks a System Architecture is designed allocating funtions to different components. Therefore we have to consider functional and safety system requirements that are decomposed in mechanical, electrical, hardware, software and other requirements.

For software components, we define high and low level software requirements, implemented in different software coding units. Per each of those requirements we have to define test procedures and test cases that are run in test campaigns that collect test results.

Visure Requirements is able to support all this process from risk analysis, system requirements, high and low level software requirements, coding units, test cases and test results, providing top to bottom and bottom to top traceability.

More details can be found on:
https://visuresolutions.es/visure-requirements-funcionalidades/
Fernando Varela
Olivera Stojanovic
How to verify Complex Electronic Hardware (FPGAs, SoC) under DO-254 safety standard

Depending on the DO-254 level, you don't need HW Detailed Design and testing can be only functional black box testing. But for Level A and B, you are required to verify the Detailed Design and perform white box testing into the SoC.

In that cases, it's important to have an experienced verification strategy that allow to reduce the verification effort for the more complex SoC.

This presentation will show how to fulfill the verification planing and tracking, including verification execution, debug and reporting

More details can be found on:
https://www.hdl-dh.com/services/complete-soc-verification/
José Luis March Cabrelles
Qualifying embedded compilers and detecting vulnerabilities


Compilers are 'just' tools in any functional safety standards.  They need the highest qualification levels, however are really difficult to qualify. Developers prefer to do on-target application testing over compiler qualification. This does however not take into account the complexity of a compiler and the artifacts it introduces in the generated code, not to mention who has responsibility for the correctness of an open source compiler.

In 2008, a buffer overflow bug was detected in a function that perfoms domain-name lookups in the GNU C Library. In 2017, a vulnerability codenamed Devil's Ivy was detected in gSOAP, a C/C++ library. There were some other important vulnerabilities discovered in the last years.

The presentation will discuss compiler qualification according to a functional safety standard, the impact of optimizations on source code coverage and code coverage of the compiler itself.

More details can be found on:
https://solidsands.nl/supertest
Detalle de Ponencias (Track 1)
Inscripcion Doymus Dev Tools 2019
Doymus Dev Tools 2019

Madrid, 2 de Abril de 2019
Inscripcion Doymus Dev Tools 2019
Productos
 
©  2014 - 2019 Doymus Software e Ingeniería  •  Aviso Legal  •   Política de Privacidad  •  Política de Cookies
Servicios
Contactar
+34 911.788.540
info@doymus.com
Software & Hardware Development Tools
and Professional Services
Otros
Referencias

Recursos

Newsletters

Eventos
Doymus
Análisis Estático de Código Fuente y Binario
Placas y Sistemas Hardware
de Alta Disponibilidad
Validación y Simulación
de Requisitos
Pruebas de Integraz Gráfica
de Usuario (GUI)
Entornos de Desarrollo Software Embarcado
Especificación y Análisis de Requisitos y Riesgos
Pruebas dinámicas de Software Embarcado
Soporte a la Certificación ISO-26262
Formación DO 178/254
Soporte a la Certificación DO 178/254
Diseño y Verificación
de SoCs y FPGAs
Doymus distribuye productos y servicios de las siguientes compañías:
Este sitio web usa cookies para recopilar información estadística sobre su navegación. Si continúa navegando, consideramos que acepta su uso. Más información en: Política de Cookies