How Cognition Cockpit Improves Development Processes at Cummins, Inc. Cummins Inc. (www.cummins.com) is a $10B company that is in business to design, manufacture, distribute and service engines and related technologies. To manage their complex set of technical processes Cummins needed a cohesive, broad-based, inter-linked database that was easily accessible by all team members in various functional areas. Cummins has found starting over ten years ago that Cognition Corporation s Cockpit system engineering tool met this need. The diagram on the next page depicts Cummins transition to using the Cockpit tool. Cummins also has recently expanded the Cockpit tool beyond technical processes to also support a wide variety of business processes. Several of Cummins Value Package Introduction [VPI] projects (new product design and development) are being supported by the tool in a cross-functional manner. The projects include the following VPI areas which interact throughout their stage-gate process: Program Leadership Technical Manufacturing Purchasing Marketing Application Engineering Customer Care (Distribution, service & after-sales support) Summary of Benefits Cummins derives from the Cockpit Tool: Cockpit Tool coordinates diverse activities at a detailed, parameter-based levels of interaction The tool links Requirements and Evidence documents and data directly to development activities Web-based presentation allows all team members to interact without special software Page 1 of 14 www.cummins.com www.cognition.us
Cummins Transition to the Cockpit Tool Figure 1
This Case Study illustrates how these benefits are achieved; included are several screenshots from Cummins actual Cockpit model. For example, Figure 2 shows the above-mentioned set of Cummins Value Package Introduction (VPI) evidence management categories listed in the tool. Figure 2 Cummins holistic usage of the Cockpit tool provides the company the ability to unify and synchronize diverse development activities. These development activities include: A. Evidence/Document Management B. Requirements Management C. Design-for-Six-Sigma support (DFSS)/ Critical Parameter Management (CPM) D. Failure Mode Effects Analysis (FMEA) and Risk Management F. Test Engineering (validation & verification activities) This Case Study discusses each of these activities. Cummins observes that Each function (department) uses Cockpit but with different focus on content and activity when they are in Cockpit. The Technical function utilizes the tool the most, especially with managing requirements.
Cockpit Tool Deployment at Cummins Cummins currently has over 500 Cockpit users, with a mix of local and remote users; with about 10% located overseas. Support for the Cockpit tool is tied in with the Cummins IT Help Desk ticket system as well as Cognition s Help Desk and Application Engineers. Users also are encouraged and have been using Cognition's help desk for support questions as well as enhancement suggestions. This is available via a built-in web form link in the Cockpit tool. Less than one full-time person administers the tool within Cummins. Support is facilitated through the use of templates that are placed into the tool by Cummins lead users. Working in conjunction with support personnel from Cognition Corporation, Cummins has developed a number of authoring templates to allow casual users to directly contribute to the project database while in familiar Office-type environments. Template design was made much easier because of the Cockpit advanced class provided last year by Cognition. Cognition's application engineers are also very helpful in setting up project structures and Cockpit documents with new users. Earlier in the year, Our biggest hang-ups have been getting more licenses (waiting on a purchase order to be issued) and increasing our server speed to react to the additional users. Cognition is very receptive to suggestions. Cummins has since increased their licenses and are no longer limiting access due to licenses. What Cummins Uses the Cockpit Tool For A. Evidence Management Evidence management involves the collection, cataloging, and storage of a wide variety of documentation that demonstrates how requirements and processes have been satisfied in a development effort. Cummins has made good use of the Cockpit tool as a collaborativelyaccessible method for hosting evidence. Because all of the evidence collected becomes part of the single comprehensive Project Model, it is all linked to relevant model elements.
We use Cockpit to store all of our primary evidence for program deliverables according to our VPI process, linking project management activities with systems engineering activities such as requirements management. With other methods shared network drives, Lotus Notes discussion databases / teamrooms, and internal Wiki pages it is more difficult to control the quality of the primary evidence for a program. Multiple methods to view and relate the documentation are possible within Cockpit. For example Cummins uses: A tabular document view showing attachments that are linked to project VPI process requirements The built-in file explorer view in the Table of Contents And finally, an easy-to-use integrated Google indexing capability that leverages a Google Appliance to provide search results to users who need not be familiar with the data and knowledge management storage architecture. Figure 3 illustrates how Cummins has used Cockpit s integrated Google search capability, as well as the Table of Contents and tabular view of the same attachment. This Google search covers not only all detailed information within the project s Cockpit model, but also the content of Office-like documents stored in the tool for the model. Figure 3
B. Requirements Management Requirements Management is a central capability of the Cockpit tool. The tool captures and manages requirements in a rigorous database/historical fashion. Any good requirements tool will do that. But two capabilities of the tool do set it apart. One capability is the tool s ability to not only manage textual requirements, but also explicitly manage any numerical parameters associated with the requirement. The other valuable capability is that in one unified model, architects and designers can not only co-manage the requirements themselves, but also can provide dynamic traceability within the model of Cummins activities relative to a system s Architecture, Design, Development and Verification. Cummins uses the Cockpit tool for Requirements Management and the flowdown of system voices to system requirements on down to component specifications. The ability to link and associate requirements in a structured database with parent-child and peer-peer relationships is new for our VPI process and is critical to managing the functional interactions among those levels. The built in views around traceability are also very useful for analyzing relationships among objects in the database. Figure 4 shows a diagram that is focused on an Incremental weight System requirement in the central oval; the diagram is dynamically produced by the tool based on current data. Antecedent drivers are shown above; allocation to subsystems show below. Figure 4
Figure 5 gives an example of how Cummins has used Cockpit s built-in parameter variational analysis capability. In the diagram the Incremental weight parameter has been assigned a target value of being less than 430.9. Realized values of the parameter have been captured, and their statistics and distribution presented by the tool automatically. Figure 5 In addition to using the tool s built-in parameter analysis tools as indicated above, Cummins also utilized the tool s direct bidirectional linkage to both Excel and Matlab. So, engineers preferring to work in these environments may do so while remaining aligned with current data in the Cockpit database. The Cockpit tool also provides bidirectional data linkages with Microsoft s Visio drawing tool in order to generate or express detailed Cockpit data in Visio s rich graphical environment. Additionally, Cummins found the Cockpit tool far easier than other Requirements Management tools for users to get productive with. Even though the tools could perform similarly given enough time and effort ($), the level of effort to get going and to be productive with Cognition Cockpit is much lower. One of the methods to reduce adoption was in the creation of an application of document templates within the Cockpit tool. For example, Cummins created a standard outline for a technical requirements document, and then each sub-system and assembly owner in that project used that template to enter the requirements and specifications into Cockpit. Figure 6
shows how the tool s built-in Flex-Edit graphics depicts this document template s logical structure; the structure is editable in this graphical environment. Figure 6 Cummins then generated a simple PowerPoint training module to show the prospective document owners what requirements go into the document and how to enter them with reference to Cognition s Wiki pages where appropriate. Again, multiple methods for entering data into Cockpit improved the adoption rate of the tool interface at Cummins. Several users preferred the Flex Edit graphical outline view to enter and structure requirements, while others used a Cockpit-supported Excel bi-directional interface to import and export requirements that already existed in an internal Excel table format. Other users preferred to enter requirements directly in the traditional WYSIWYG formal requirements document (Office-like). The ability to have rich text (graphics, attachments, and other collaboration data) attached to individual requirements as well as rich text introduction sections to portions of the requirements document greatly improved the accuracy and context of use of the requirements for team communication and validation/verification activities. Prior to using the Cockpit tool, these requirements were communicated via Excel spreadsheets, with target values and in some cases external links for additional information.
C. DFSS Support and Critical Parameter Management (CPM) The Cognition Cockpit tool was designed from the beginning as a means of supporting Design- For-Six-Sigma (DFSS) processes. As such, Cummins has been recommending the Cockpit tool to support their DFSS projects. The Cockpit tool was designed from its inception to manage critical parameters, a capability critical to DFSS. The tool provides a robust capability to treat parameters in a requirement context, assign target values, manage design values, maintain history, analyze and combine parameters, perform Monte Carlo analyses, and report margins according to selectable criteria. Cummins has been with working with Cognition & their Cockpit database since the beginning to perform Critical Parameter Management. We have had several in-depth projects utilize the tool, and several individual projects apply the tool to track critical parameters, produce QFD House of Quality matrices, and produce CPM scorecard reports. In Figure 7, Pen Engagement Force is not merely a textual requirement, but also is an actual parameter that the tool will trace and analyze numerically: Figure 7
Figure 8 illustrates numerical tracing and analysis of the Pen Engagement Force parameter done in the tool. Figure 8 Figure 8 also shows several component parameters feeding into the Pen Engagement Force parameter. There are variational analyses and target values for these parameter values. Figure 9
D. FMEA (Failure Modes and Effective Analysis) Currently, Cummins is piloting Cockpit to perform our FMEAs for risk management. Additionally, Cognition is working with other of its customers on expanding the built-in FMEA capabilities of the tool, including use of the tool s direct bidirectional mapping to items within linked Visio drawings that show relationships and data in a diagrammatic fashion. Figure 10, below, provides an example of the tool managing and assisting in the preparation activities leading up to creating a traditional FMEA form. This assistance is provided via Cockpit Templates as well as progressive documentation which builds upon itself, enabling the user to create in the tool and have a work process that documents itself. In this example the user is assisted in finding and assigning system functions to interface groups. The pop-up bubble provides a rapid search capability for locating functions for assignment. Since the FMEA process has such a high percentage of shared relationships among functions, requirements, tests and other collaborative information it naturally makes sense to have those items all managed in one cohesive data model such as Cockpit. This reduces the amount of error moving between tools and improves the sharing of information, better enabling a common mental model among engineers. Figure 10
F. Test Engineering Cummins currently is working toward replacing an existing Microsoft Access-based test data system. Incorporating Test Engineering leverages Cummins existing comprehensive Requirements/Design/Verification investment in the Cockpit tool. The ability to complete the cycle through Voices to Requirements to Verification Tests at multiple project milestones within one database tool promises to aid Cummins in traceability and reduce dependence upon multiple databases and individual spreadsheets.
Benefits of the Cockpit Cummins has noted the benefits of the tool in three areas: 1. Process Support (The Cockpit tool) enables Systems Engineering with pre-programmed structure and built-in flexibility. Cockpit provides a rich systems engineering solution. Furthermore, Process established with one Cockpit project may be reused as built-in process for a subsequent Cockpit project. 2. Ease of Use, Quick production of Specs With only a few minutes (20-30 minutes) of explanation and demonstration, Cummins has users start authoring documents via Cockpit templates within that same time period. The entry hurdle to be productive is very low as the interface is Microsoft like and there are many pop-up tips, on-line video tutorials, and wiki pages available to the users for on-demand questions and training. Effective program management is provided connecting product development deliverables and Design for Six Sigma deliverables with their evidence. This is a key differentiator, showing the user full traceability from Voices to Requirements through Risks and Verification tests in an intuitive web interface. [emphasis added] 3. Configuration Management and Consistency Cockpit allows us to manage our documents with ownership / editing control and baseline capabilities throughout the program cycles.
Summary: The Big Picture at Cummins Cummins themselves summarize what the Cockpit tool has meant to their total cross-functional development environment: Within the past year, we have recently utilized Cockpit as an evidence management (PLM lite) system for two major new product introduction programs at Cummins utilizing our VPI (Value Package Introduction) process. Although the controlled document management is a main focus for most team members, the power of the tool comes in utilizing it for Requirements Management and the process surrounding that. Gathering the Voice of Customers, translating those voices into requirements, and then managing those requirements by measuring their design model, process model, and actual test data throughout a development program is the real power of Cockpit. [emphasis added] Traceability is the key here. The Cockpit tool provides users with easy-to-access tracing between all items linked together in the Project s model, right down to individual parameters. Like all aspects of the tool, the access is up-to-date, Web-based, and simultaneous among multiple users worldwide.