First published 2013 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address:
ISTE Ltd
27-37 St Georges Road
London SW19 4EU
UK
www.iste.co.uk
John Wiley & Sons, Inc.
111 River Street
Hoboken, NJ 07030
USA
www.wiley.com
ISTE Ltd 2013
The rights of Fabrice Kordon, Jrme Hugues, Agusti Canals and Alain Dohet to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.
Library of Congress Control Number: 2013932630
British Library Cataloguing-in-Publication Data
A CIP record for this book is available from the British Library
ISBN: 978-1-84821-500-9
Foreword
I am pleased to be asked to write this preface for two reasons. One was to provide fair evidence in favor of pre-existing prejudices. The other was to see the use of the PACEMAKER System Specification as a common subject for the application of SysML, MARTE, and AADL.
Previously only familiar with SysML and MARTE through presentation and tutorial, I expanded and sharpened my understanding of their adaptability to each users (companys) needs. From UML, SysML and MARTE come notations that neither prescribe nor proscribe design methods or tools. The power of defining ones own semantics comes at the cost of defining ones own semantics.
In the domain of embedded electronic control systems using software, AADL reigns supreme. I serve on SAE International AS-2C standard subcommittee that issues the AADL standard and its annex documents, so please understand my enthusiasm in the context of a true believer. AADL is not suitable for modeling an entire aircraft, just its avionics. Where SysML/MARTE hands-off to AADL for electronics and software architecture should be at the edge of the electronics (sensors, actuators, displays). Lowest-level SysML/MARTE components trace to top-level AADL components.
Tracing between SysML and AADL might be done using RDALTE which links requirements to architecture. Currently RDALTE links to AADL, using OSATE2, but it is designed to be architecture agnostic. To easily add linking to SysML/MARTE models is a feature of RDALTE.
More personally, the PACEMAKER System Specification used in this book and many published papers was provided by Boston Scientific for use in research and education as a public service. Its origin was serendipitous.
While attending Formal Methods 2006 held at McMaster University in Hamilton, Ontario, I happened to catch a ride with Jim Woodcock. Jim originated the Verification Grand Challenge problem of a Mondex electronic wallet used as the subject of several papers at the conference. Mondex was a clean, simple problem for which a specification had been written in Z. Given the dearth of conference attendees from industry Jim pounced upon me exhorting a real-world problem, complex enough to challenge formal methodologies, but not so large as to preclude use by small, academic teams. I told him Id try to find such a problem.
Rooting around, I found a concise, system specification of a pacemaker designed in the 1990s that was company confidential. However, the companys confidentiality policy made no mention of publicly releasing confidential documents akin to declassification of secrets. Therefore approval of public release would need to come from upper management. With the assistance of many people in Boston Scientifics Formal Methods Group, the document was converted to LaTeX, stripped of proprietary content and mentions of Boston Scientific products, and repeatedly reviewed. The Software Quality Research Laboratory at McMaster University agreed to host the document and its FAQ. Finally, all approvals were obtained, and the document released, six months after that fateful car ride with Jim.
This book succinctly explains three popular languages used to model systems, each complex subjects themselves, in remarkably few pages. Those that want to understand fundamental concepts and differences of SysML, MARTE, and AADL will find this books use of a common subject helpful.
Brian R. LARSON
Research Associate, Kansas State University
U.S. Food and Drug Administration Scholar in Residence
March 2013
Requirements Development and Analysis Language Tool Environment.
for more details.
Foreword
In the introduction to the report of the mission Generic embedded software components, which was entrusted to me in 2010 by the French Minister for Industry, the Secretary of State for Forward Planning and Development of the Digital Economy, and the General Commissioner for Future Investments, there is a reminder that:
The technologies of embedded systems, embedded software, and microelectronics have the capacity to transform all the objects of the physical world from the smallest to the largest, from the most simple to the most complex into digital, intelligent, autonomous and communicative devices. The emergence of the Web of Objects, the connection between the world of the Web and the world of embedded systems, considerably amplifies this revolution.
Indeed, the general deployment of embedded systems significantly changes our environment, has brought about numerous innovations in products and uses, and impacts all industrial activities and services.
Mastering the engineering of embedded systems is, therefore, a key element in industrial competitiveness. However, achieving this mastery is still a complex and costly process because of the breadth of the technological field, the diversity and complexity of requirements and solutions. This is illustrated well by the different views of this type of engineering proposed by the embedded systems common technical baseline or CTB:
The system view describes the actual embedded system, that is its architecture, and all its hardware and software components (processing units, bus and operating system (OS) networks, middleware, application software).
The design tools view shows all the design tools (modeling, simulation) used.
The lifecycle view of the product describes the activities and where they are involved in the design, development and implementation of an embedded system.
Figure F.1.System views (left), lifecycle (center) and design tools (right)
Examination of these different views shows the importance of modeling activities in embedded systems engineering. Therefore, with each level and each element in the system view architecture, processors, bus and networks, software, etc. correspond, as shown in the lifecycle and design tools of the product, the models and modeling tools that assist and validate the different stages of development.
Next page