Control Software Interface for Managing System Requirements

Transcription

1 SAE TECHNICAL PAPER SERIES Control Software Interface for Managing Requirements Gary Rushton and Amy Wesley Visteon Corporation Armen Zakarian and Tigran Grigoryan University of Michigan Dearborn Reprinted From: Software/Hardware s, s Engineering, Advanced Electronics Packaging, and Electromagnetic Compatibility (EMC) (SP-1857) 2004 SAE World Congress Detroit, Michigan March 8-11, Commonwealth Drive, Warrendale, PA U.S.A. Tel: (724) Fax: (724) Web:

2 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. For permission and licensing requests contact: SAE Permissions 400 Commonwealth Drive Warrendale, PA USA permissions@sae.org Fax: Tel: For multiple print copies contact: SAE Customer Service Tel: (inside USA and Canada) Tel: (outside USA) Fax: CustomerService@sae.org ISBN Copyright 2004 SAE International Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE. The author is solely responsible for the content of the paper. A process is available by which discussions will be printed with the paper if it is published in SAE Transactions. Persons wishing to submit papers to be considered for presentation or publication by SAE should send the manuscript or a 300 word abstract of a proposed manuscript to: Secretary, Engineering Meetings Board, SAE. Printed in USA

3 Control Software Interface for Managing Requirements Gary Rushton and Amy Wesley Visteon Corporation Armen Zakarian and Tigran Grigoryan University of Michigan Dearborn Copyright 2004 SAE International ABSTRACT Not all software tools are created equal and not all software tools are created to perform the same tasks. Therefore, different software tools are used to perform different tasks. However, being able to share the information between the different software tools, without having to manually re-enter (duplicate) any of the information, can save a lot of time and improve the quality of the product. The control software interface presented in this paper, allows system engineers to exchange data between software tools in an efficient manner which maximizes each tools capabilities and ultimately reduces development time and improves the quality of the product. INTRODUCTION In this paper, a control software interface is presented that allows system engineers to exchange requirements data between system modeling, system optimization, and system requirements management software tools. modeling tools allow system engineers to graphically capture the system requirements at various levels of detail. optimization tools allow system design engineers to develop low cost architectures that support multiple configurations from the system requirements model. optimization tools identify the optimal system architecture for a given product/system feature set and feature take rates by grouping (integrating) system functions into physical modules and determining the best possible tradeoffs between system overhead, give away, and wiring costs. requirements management software tools allow system engineers to capture and organize system requirements in a way which can enables all stakeholders to communicate, collaborate and validate requirements, as well as provide bi-directional tracability for all system requirements. MAIN SECTION s Engineers have a copious toolbox of methods at their disposal for doing system's analysis and trade studies. One such method being used at Visteon is the Hatley-Pirhbai Method. This method allows the systems engineer to create requirements models and architecture models of the system. The Hatley/Pirbhai methodology is the only real-time methodology that develops both the functional requirements and the physical requirements of a system. Models generated from this method address the behavior of the system in response to external stimuli (requirements model), as well as, the physical structure of the system being specified (architecture model). While system modeling tools in general, help engineers to understand functional requirements in a way that textbased requirements cannot, there are various types of requirements analysis that can only be accomplished with text-based requirements. For example, the ability to label each requirement with attributes like Priority, Owner, or Level of Completeness can only be done when the requirements are in a text-based format. By doing this in a tool like DOORS, the engineer can filter, sort, and perform a variety of queries, which are important in the product development process. A commercially available software called TurboCASE/ Sys, created by Structsoft, fully implements the Hately- Pirbhai methodology. TurboCASE/Sys, on its own, does not have a mechanism that allows attributes to be attached to requirements.

4 It is important to keep in mind that requirements models and text-based requirements do not have to be an either/or situation, especially when an interface can be developed. In order to bring requirements models and requirements documents together, we defined an interface with the following features: Export surrogate objects to DOORS Keep surrogate objects associated with the model elements which they represent Ability to synchronize surrogate objects in the event that the model was changed By having this much functionality we could at least ensure that the engineer could start his/her normal activity, which involves creating the requirements model in TurboCASE/Sys. Next, the engineer exports that data to DOORS, creating the surrogate objects that represent the model elements. Additionally, the engineer has the ability to re-synch the DOORS surrogate objects with the TurboCASE/Sys model as the model changes. This process is illustrated in Figure 1. The interface allows the engineer to follow his/her normal process for capturing functional requirements in TurboCASE/Sys by first performing a functional decomposition. Figure 2 contains a screen shot from TurboCASE/Sys showing the highest level functional diagram, the context diagram. The context diagram is used to define the scope of the system under design (what is inside the system and what is outside the system). Once the system boundaries and external entities are established, the interactions between the system and the external entities are identified. The external entities that the cockpit system interacts with are represented as terminators (rectangles) on the context diagram (see Figure 2). The engineer then uses TurboCASE/Sys to create lower level functions (see Figure 3) until the functions cannot be decomposed any further (see Figure 4). Figure 3 is the child diagram of the context process shown in Figure 2 and presents the interactions among the six functions of the cockpit system. The electrical/ electronic functions of a cockpit system can be decomposed into six main functions (processes) as shown in Figure 3. Each process in Figure 3 is decomposed to the lowest level processes, i.e., primitives (PSPECs). TurboCASE/Sys also allows the engineer to create corresponding architectural models that represent a hierarchy of the physical system. The engineer then associates functions and architecture in order to show traceability between requirements and design (Rushton, G. and Zakarian, A. 2000). Ultimately, the model information from TurboCASE/Sys is stored in an Access database (see Figure 1). The data in the Access database is used in an optimization algorithm to aid in the architecture tradeoff process (Rushton, G., Zakarian, A., and Grigoryan, T. 2002). The graphical hierarchy produced in TurboCASE/Sys becomes a text-based hierarchy in Access. Since DOORS formal modules are designed to manage a text-based hierarchy, it was very easy for the information to be exported from the Access database to DOORS. The resultant surrogate module appears in Figure 5. The TurboCASE/Sys model elements are exported to DOORS from the Access database via a drop menu selection found in the DOORS Database Manager's File menu. The user must have a project or folder already open in which to export the data from TurboCASE/Sys. In addition to exporting the functional hierarchy, other data, such as the system features requested by the customer, are exported into separate DOORS modules. The relationships among these different types of data are then characterized in DOORS by links. The export routine creates the link modules, link-sets and the links during the initial export of TurboCASE/Sys data into DOORS. (see Figure 6) The interface software is comprised of two main DXL routines: an export routine and a synchronization routine (Wesley, A., Rushton, G., Zakarian, A., and Grigoryan, T. 2003). The export and synchronization DXLs make use of the ability of DOORS to control other Windows applications that provide automation interface objects. Since the TurboCASE/Sys requirements model information is stored in an Access database, we are able to get the necessary information by taking advantage of the OLE function calls defined in DXL. DOORS Links are created between those items in the requirements models that "interact" with each other. These interactions are initially captured and stored in the Access database; that is the source of the data imported by the interface software. Those interactions are extracted during the import process and captured such that DOORS links can be created between the surrogate modules. When the data is initially imported into DOORS modules, an object attribute is created to capture the original Access database OLE object's identifier number. Keying off of this number enables the synchronization feature to match and update the appropriate objects, create new objects, and even delete those objects which have been removed from the TurboCASE/Sys requirements model. With the TurboCASE/Sys requirements model information now in DOORS, the engineer can link the functional/behavioral requirements to customer requirements and non-functional requirements also being managed in DOORS. Thus, the engineer can be confident that they have captured not only what the system must do, but also what it is constrained by (Rushton, G. and Merchant, V. 2000). The European Union's End of Life Vehicle Directive is a very poignant example of a serious constraint on vehicle and vehicle

5 systems design. If any such non-functional requirements are ignored or are considered too late in the product development process, it could be very costly and time consuming. CONCLUSION A very compelling reason to use DOORS for requirements management is the tool's flexibility via DXL and the API. In Visteon's case, we were able to design and build an interface between DOORS and TurboCASE/Sys to allow requirements models and requirements documents to compliment one another. Creating an interface like this also allows the engineer to build the big picture of the system so that he/she can consider the functional as well as the non-functional requirements of the system. Another benefit of DOORS is that it allowed Visteon to work with a specific, purpose-built tool, without having to sacrifice any of the functionality needed. For engineers who practice the Hatley-Pirhbai method of system design and analysis, this is an important factor. Thus, our engineers were not forced into a situation of using a systems design and analysis tool that did not meet their needs, but one that integrated with DOORS. This can be a serious drawback for other requirements management tool sets that only integrate with certain design and analysis tools. s Engineering teaches us to think about processes, methods and tools, in that order. The flexibility of DOORS as a tool allows Visteon to support a wide variety of methods, which, in turn, allows Visteon to implement specific processes, reduce product development time, and improve product quality. ACKNOWLEDGMENTS This research was supported with a grant from Visteon Corporation. REFERENCES 1. Rushton, G., Zakarian, A., and Grigoryan, T. (2002), Algorithms and Software for Development of Modular Vehicle Architectures, SAE World Congress Wesley, A., Rushton, G., Zakarian, A., and Grigoryan, T. (2003), Requirements Models and Requirements Documents: Bridging the Gap with the DOORS API, Telelogic Users Group TUG Rushton, G. and Zakarian, A. (2000), Modular Vehicle Architectures: A s Approach, Proceedings of the Tenth Annual International Symposium of the International Council on s Engineering, pp Rushton, G. and Merchant, V. (2000), Vehicle Electrical/Electronic Design Considerations, SAE World Congress CONTACT Gary Rushton has over 18 years of commercial and military electrical/electronic systems engineering experience. He has an MS in Automotive s Engineering from the University of Michigan. He is currently working as an electrical/electronic systems engineer Technical Fellow with Visteon Corporation. As an engineer with Visteon Corporation, he has worked on audio software, subsystem product development/design, diagnostics, vehicle system architectures, and cockpit system design. Previously, with General Dynamics, he worked on avionics systems for the F-16 and vetronics systems for the Abrams M1A2 main battle tank. (grushton@visteon.com). Amy Wesley is currently working as a Engineering Tools Analyst with Visteon Corporation. She has been working in the area of s Engineering and Requirements Management tools since She received her B.A. degree in history in addition to a Michigan Provisional Secondary Education Certificate from the University of Michigan Ann Arbor. She is currently a M.S. degree candidate in the Industrial and Manufacturing s Engineering Department, at University of Michigan Dearborn, focusing on Human Factors Engineering. (awesly@visteon.com). Armen Zakarian received his B.S. degree in mechanical engineering from Yerevan Polytechnic University, Yerevan, Armenia, his M.S. degree in industrial and systems engineering from the University of Southern California, Los Angeles, California and his Ph.D. degree in industrial engineering from the University of Iowa, Iowa City, Iowa, in He is an Assistant Professor of Industrial and Manufacturing s Engineering at the University of Michigan - Dearborn. His research interests are in development of integrated products and system, process modeling and analysis and manufacturing system. He has published papers in journals sponsored by ASME, IEEE and IIE societies. (zakarian@umich.edu). Tigran Grigoryan received his B.S. degree in applied mathematics and computer science from Yerevan State University and his M.S. degree in applied mathematics from Yerevan State Engineering University. He is currently M.S. degree candidate in Industrial and Manufacturing s Engineering Department, at University of Michigan - Dearborn. He is interested in operations research and computational intelligence. (tigr@umich.edu).

6 DOORS TurboCASE/Sys DOORS Surrogate Module 1.0 Element 1.1 Subelement 1.2 Sub- element 2.0 Element Text-based SRD 1.0 Introduction 2.0 Desc Dynamic interface exports the elements of the model and any other information from TurboCASE/Sys to DOORS and creates a surrogate object for each element exported. Dynamic Interface would allow automatic traceability to and from DOORS and TurboCASE/Sys. TurboCASE/Sys Access DB T- files Database files contain the data which makes up the model. DOORS links 3.0 Requirements 3.1 The system shall 3.2 The system shall Text-based SRD Baseline 1.0 Introduction 2.0 Desc 3.0 Requirements Dynamic interface would prompt user to synchronize data from the model to the surrogate objects in DOORS. Interface would handle the synchronization if the user chose to do synch the DOORS objects to the model. 3.1 The system shall 3.2 The system shall Figure 1: Overview of Interface and Process

7 Provide Electrical and Electronic Functions of a Cockpit.0 User Doors and Trunk Powertrain Control Restraint Control Horn Exterior and Interior Lights Passenger Compartment Wireless Information Brake Pedals Operating Environment Steering Wheel and Column Speakers AntiLock Brake Fuel Speed Control Vacuum Wiper/Washer Windows and Mirrors FUEL S ATMOSPHERIC CONDITIONS RESTRAINT USER REQUESTS USER FEEDBACK VACUUM PRESSURIZED DOOR AND TRUNK DOOR AND TRUNK S AMPLIFIED AUDIO SPEED STATE PEDALS STATE HORN ANTILOCK WIRELESS INPUTS WIRELESS OUTPUTS WASHER FLUID CONDITIONED COCKPIT CONDITIONS IGNITION SWITCH HEATED REAR WINDOW SEAT BELT ON ENGINE DATA Figure 2: Cockpit Context Diagram

8 RADIO PRESENT SEAT BELT SEAT BELT ON REMOTE TIC ANTI-THEFT INFORMATION INTERIOR.5 COMMUNICATION EARTH ENVIRONMENT AND Provide MAGNETIC SETTINGS SUNLOAD ENTERTAINMENT Interior FIELD INTENSITY SETTINGS VACUUM Comfort ACCESS PRESSURIZED RESTRAINT SETTINGS CLIMATE HORN SETTINGS DOOR AND ENGINE TRUNK COOLANT VEHICLE AC CLUTCH.3.1 S FLUID SPEED OVERRIDE TRANSMISSION TEMPERATURE Provide TRANSMISSION Protect Occupants and Cargo REMOTE HORN KEYLESS DOOR ENTRY AND SETTINGS TRUNK LOCK S WASHER FLUID VISIBILITY SETTINGS ENGINE CONDITIONED HEAT PEDAL LOCATION COCKPIT CONDITIONS ANY DOOR AJAR.4 Provide Visibility AMBIENT LIGHT VEHICLE SPEED KEYPAD ILLUMINATION RAM/FRESH INSIDE POWERTRAIN SYSTEM TRANSMISSION VEHICLE SPEED VISBILITY HEATED REAR S WINDOW WASHER FLUID BATTERY SAVER S DOMELAMP ATMOSPHERIC CONDITIONS KEY IN IGNITION WIRELESS INPUTS HEADLAMPS KEYPAD ILLUMINATED ENTRY Information, Communication, and Entertainment CHIME DELAYED BATTERY ACCESSORY SAVER.6 Control Power Distribution VALID IGNITION REMOTE SETTINGS PRESENT EMERGENCY EMERGENCY VEHICLE MOTION WARNING FUEL FUEL ENGINE FLUID STATES ABS IGNITION SWITCH WIRELESS OUTPUTS.2 Provide Vehicle Motion FLUID VISUAL INDICATORS VISUAL DRIVER WARNINGS AND INDICATORS AMPLIFIED AUDIO ANTILOCK PEDALS STATE SPEED STATE ON OFF Figure 3: Cockpit Data Flow Diagram (DFD 0) CONTEXT 0 DFD Figure 4: Decomposition of Functions in a TurboCASE/Sys Requirements Model

9 Figure 5: DOORS Screen Shot of Imported TurboCASE/Sys Requirements Model Hierarchy Figure 6: DOORS Screen Shot of Formal and Link Modules Created upon Import