Debugging Embedded Systems Requirements before the Design Begins

Seite: 5/5

Anbieter zum Thema

STIMULUS generated this problematic test case by automatically exploring a large number of control modes and mode changes, as well as various light intensity ranges and variations. Even with such a limited case, the combination range would already be wide enough for a manual testing not to explore all interesting scenarios. With STIMULUS, the process induces little work since, instead of describing specific individual test cases, it relies on test cases “classes” defined by constraints.

Of course, STIMULUS does not guarantee a complete exploration of the state-space, but it provides coverage information on both the scenarios and the requirements. At last, the test objectives are not derived any more from the requirements since they are the requirements themselves. In other words, the system implementation is directly validated against the original requirement formulation, which has been formalized and already validated during the requirements specifications process.

Bildergalerie
Bildergalerie mit 11 Bildern

V. Conclusion

In this paper, we have presented STIMULUS, the first commercial tool that brings simulation capabilities at the specification level to allow for the early validation of functional embedded system requirements. This tool offers totally new and effective features for system architects to make requirements right the first time and validation engineers to check that the system implementation satisfies its requirements.

The ability to formalize textual requirements which are close to the natural language, while being perfectly defined, allows for development teams and stakeholders to share non ambiguous requirements that can fit to the specific application domain a well as to the culture and usages of the company. This textual language is also useful for describing non deterministic test scenarios that will generate a class of test vectors, in other words, the tool will explore an envelope of the test scenario (different variations and combinations of signals within the possible behaviors).

When defined, debugged and validated together during the specification process, both requirements and test scenarios can be reused to test the system implementation. Since this test environment is available before the design begins, it provides a great support to agile processes, where the implementation code can be validated in a very automatic and incremental way: test vectors can be generated automatically each time a new implementation is available and requirements can be checked automatically through requirements observers.

In terms of scalability, STIMULUS provides a natural way of validating system requirements by “layers”. At a given system level, requirements are defined with respect to inputs/outputs. If this system level is made of different sub-systems, these requirements can be refined into low-level requirements that will be allocated to sub-systems, and so on, following the block diagram hierarchy. Future work includes the use of reachability analysis, when applicable, in order to guide simulation traces towards interesting points, for debugging purpose, or in order to explore rare paths and improve test coverage of requirements and scenarios.

This article is taken from the conference proceedings of the Embedded Software Engineering Kongress 2016.

References

[1] K. Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques, Springer Publishing Company, Incorporated, 2010.
[2] G. J. Myers and C. Sandler, The Art of Software Testing, John Wiley & Sons, 2004.
[3] B. Jeannet, Debugging Real-Time Systems Requirements : Simulate The “What” Before The "How", Nürnberg: Embedded World Conference, 2015.
[4] P. Abrahamsson, J. Warsta, M. T. Siponen and J. Ronkainen, New directions on agile methods: a comparative analysis, Washington, USA: Proceedings of the 25th International Conference on Software Engineering, IEEE Computer Society, 2003.
[5] IEEE 29148 - Systems and software engineering -- Life cycle processes -- Requirements engineering, IEEE STANDARDS, 2011.
[6] A. Fraga, J. Llorens, L. Alonso and J. Fuentes, Ontology-Assisted Systems Engineering Process with Focus in the Requirements Engineering Process, Fifth International Conference on Complex Systems Design & Management (CSDM), 2014.
[7] S. P. Miller, A. C. Tribble, M. W. Whalen and M. P. E. Heimdahl, Proving the shalls: Early validation of requirements through formal methods, International Journal of Software Tools for Technology Transfer, 2006.
[8] P. Raymond, Y. Roux and E. Jahier, Lutin: A language for Specifying and Executing Reactive Scenarios, EURASIP Journal on Embedded Systems, 2008.
[9] E. Jahier, N. Halbwachs and P. Raymond, Engineering Functional Requirements of Reactive Systems using Synchronous Languages, Porto, Portugal: International Symposium on Industrial Embedded Systems (SIES), IEEE, 2013.
[10] P. Schrammel and B. Jeannet, Logico-Numerical Abstract Acceleration and Application to the Verification of Data-Flow Programs, Static Analysis Symposium (SAS), 2011.
[11] A. Mavin and al., EARS (Easy Approach to Requirements Syntax), 17th IEEE International Requirements Engineering Conference, 2009.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:44841823)