how to eat an elephant: process approach to autonomous ... · pdf fileapproach to autonomous...
TRANSCRIPT
How To Eat An Elephant: Process
Approach To Autonomous Vehicle
Development
Advanced Systems For
Transportation
Calgary, 10/25/2016
Agenda
• Complexity in modern vehicles/problem statement
• Automotive SPICE
• Engineering 1 – Engineering 3 in detail
• Prerequisites (ALM, traceability, gates, compliance matrix)
• Customer requirements and quote
• Project planning (Systems Engineering) and monitoring
• Supporting processes
10/26/2016 Disclosure or duplication without consent is prohibited 2
Complexity
10/26/2016 Disclosure or duplication without consent is prohibited 3
In the automotive realm, the explosion of
system complexity is clearly evident:
o High End vehicles use 50-80 ECU
which contain embedded software
o Approximately 20 million lines of code in
those 50-80 modules
Problem Statement:
o Manage requirements for above scope
o Prove that Verification & Validation
cover each requirement
o Plan and track the project
o Institutionalize risk management
o Manage suppliers
The Way Out: Process Models
10/26/2016 Disclosure or duplication without consent is prohibited 4
Customer
Requirements
System
Test
System
Requirements
System
Architecture
System
Integration Test
SW/HW
Test
SW/HW
Requirements
SW/HW
Design
SW/HW
Integration Test
HW/SW
Construction
V-Model Approach• From Generic to Specific
• Ensure requirements for specific step are
completely understood
• Channel into disciplines
Define the system before getting lost in the details!
This presentation will focus on
the requirements for a given
project.
Management: Project, Risk, Configuration, Issue Change, Supplier
Quality Assurance, Joint Review, Product Release
Industry Standards
10/26/2016 Disclosure or duplication without consent is prohibited 5
First CMM
Published
1987
SPICE Core
team formed
1992
CMMI
Initiative
launched
1997
SPICE
Baseline
1998SPICE
Technical
Report
1999SPICE
Usergroup
formed
2000
ASPICE
Launched
2005
CMMI Ver
1.0 launched
2000
• CMMI (Capability Maturity Model Integration) is a process improvement approach across a specific
set of processes, a project, a division or the entire organization.
• Automotive SPICE is an industry-specific version of ISO/IEC 15504 or SPICE (Software Process
Improvement and Capability dEtermination) which provides automotive industry specific process
improvement and assessment methodologies.
• HIS: “Hersteller Initiative Software”; association of German vehicle OEM; focused on the process areas
in Automotive SPICE that impact the development process the most (15 out of 31 process areas)
Process Area
Base Practices
OutcomesWork
Products
The process model documents best practices from many organizations.
The process model describes WHAT to do, not HOW to do it.
Customer Requirements (ENG. 1)
10/26/2016 Disclosure or duplication without consent is prohibited 6
The purpose of the requirement elicitation process is to gather, process and track
evolving customer needs and requirements throughout the life of the product/service
so as to establish a requirements baseline that serves as the basis for defining the
needed work products.
Base Practices
Obtain customer requirements and requests. [O1, 4].
Understand customer expectations. Ensure that supplier and customer understand each requirement in the same way. [O2].
Agree on requirements. Obtain an explicit agreement from all relevant parties to work to these requirements. [O2].
Establish customer requirements baseline. [O 3]
Manage customer requirements changes. [O3, 6].
Establish customer-supplier query communication mechanism. [O5].
Outcomes:
1.) Continuing communication with the customer is established
2.) Agreed customer requirements are defined and baselined
3.) A change mechanism is established
4.) A mechanism is established to monitor customer needs continuously
5.) A mechanism is established to ensure that the customer can easily determine the status
6.) Changes are identified, the associated risks assessed and their impact managed.
System Requirements (ENG. 2)
10/26/2016 Disclosure or duplication without consent is prohibited 7
The purpose of the System requirements analysis process is to transform the defined
customer requirements into a set of desired system technical requirements that will
guide the design of the system.
Outcomes:
1.) A defined set of system requirements is established;
2.) System requirements are categorized and analyzed for correctness and testability;
3.) The impact of the system requirements on the operating environment is evaluated;
4.) Prioritization for implementing the system requirements is defined;
5.) The system requirements are approved and updated as needed;
6.) Consistency and bilateral traceability are established between customer and system requirements;
7.) Changes to the customer's requirements baseline are evaluated for cost, schedule and technical impact;
8.) The system requirements are communicated to all affected parties and baselined.
Base Practices
Identify System Requirements. [O 1].
Analyze the identified system requirements in terms of technical feasibility, risks and testability. [O2].
Determine the impact on the operating environment, interfaces between the system requirements and other components of the
operating environment. [O3]
Prioritize and categorize system requirements. [O2,4].
Evaluate system requirements and changes to the customer’s requirements baseline in terms of cost, schedule and technical
impact. [O5, 7]
Ensure consistency and bilateral traceability of customer requirements to system requirements. [O6]
Communicate system requirements. [O8]
System Architecture (ENG. 3)
10/26/2016 Disclosure or duplication without consent is prohibited 8
The purpose of the System architectural design process is to identify which system
requirements are to be allocated to which elements of the system.
Outcomes:
1.) An architectural design is defined that identifies the elements of the system and meets the defined system requirements;
2.) The system requirements are allocated to the elements of the system;
3.) Internal and external interfaces of each system element are defined;
4.) Verification between the system requirements and the system architectural design is performed;
5.) Consistency and bilateral traceability are established between system requirements and system architectural design; and
6.) The system requirements, the system architectural design, and their relationships are baselined and communicated to all
affected parties.
Base Practices
Establish the system architectural design that identifies the elements of the system with respect to the functional and non-functional
system requirements. [O1].
Allocate all system requirements to the elements of the system architectural design. [O2]
Identify, develop and document the internal and external interfaces of each system element. [O3].
Define the verification criteria for each element of the system concerning the functional and non-functional system requirements
based on the system architectural design. [O1]
Ensure (verify) that the system architecture meets all system requirements. [O4]
Ensure consistency and bilateral traceability of system requirements to system architectural design. [O5]
Establish communication mechanisms for dissemination of the system architectural design to all relevant parties. [O6]
Traceability
10/26/2016 Disclosure or duplication without consent is prohibited 9
Goal:
Prove that all customer
requirements are
implemented.
Ensure requirements are
atomic. Prove that each
system requirement is
verified by at least one test
case.
The link between ENG. 1
and ENG. 2 ensures that all
customer requirements are
implemented.
ALM Tool
10/26/2016 Disclosure or duplication without consent is prohibited 10
Project
Planning
RQMT
ManagementSW Development Test Resources
The Application Life-cycle Model (ALM) tool needs
to tie all elements together. A well integrated tool
can manage and link the requirements, provide
versioning and KPI reports.
The example shows two products on the market;
many other products exist that allow the user to
select the desired features.
The main goal should be: As much automation as
possible, as little manual data manipulation by the
development team as possible.
Gates
10/26/2016 Disclosure or duplication without consent is prohibited 11
Quote Development Production End of Prod.
Quote
Start
Quote
Approval
Dev. Start
Design
Freeze
DV
Prod.
Tool purchase
PV
PPAPProduction part
approval processLaunch Prep
Gate milestones need to align with the deliverables
from the process model.
The deliverables can be tailored to the project
needs.
Gates are only passed if the deliverable is available.
Initial Plan
10/26/2016 Disclosure or duplication without consent is prohibited 12
0
1000
2000
3000
4000
5000
Re
qu
ire
me
nts
Customer Requirement Burndown
The requirements inventory provides the
number of documents, pages per document
and an estimate of requirements/document
as well as a prioritization.
A man power estimate can be calculated by
computing the total requirements (multiply
the number of pages by the number of
requirements per page) and multiplying this
number by the estimated time to process a
requirement.
Reuse has to be analyzed.
Consider available resources (in this
example we are adding resources in
February from another project) and then
project the requirements processed per
month.
Design
FreezeIssue: Design freeze occurs before
the customer requirements are
processed!
Customer Requirements Analysis
10/26/2016 Disclosure or duplication without consent is prohibited 13
Necessary steps to handle customer requirements:
1. Identify relevant documents from SOW
2. Procure documents
3. Distinguish between requirements and comments
4. Determine requirement ‘goodness’
5. Import the requirements into the ALM tool
This process can be handled internally or can be
outsourced since domain knowledge is not required.
Tools are available to aid with the
requirements import and goodness
analysis.
The tools can help to build an
Ontology and can import a natural
language statement based on
configurable rules.
Requirements by the numbers:
• Typical OEM projects require analysis of 120-180
documents or 2000-3000 pages
• Assuming 10 requirements per page this yields 20k
– 30k customer requirements
• Assuming 5 system requirements per customer
requirements the project will have to manage up to
150k system requirements
KPI
Alignment needed:
- Resource plan needs to match feature by phase plan
- Reports from ALM need to show that plan is on track
10/26/2016 Disclosure or duplication without consent is prohibited 14
050
100150200250300350400450
Accepted/Rejected
Blank
Review/Check
May June July
Lane
Departure
Radar
Based ACC
Feature By Phase Plan
Radar ACC Lane D. SW Eng. A
SE Eng. X
SE Eng. Y
Radar ACC
Lane Dpt.
Traffic Sign
High Speed FCA
April May June July
Resource Plan
Similar steps need to be taken for the systems requirements and the HW/SW requirements.
Reuse is a critical concept to manage the sheer number of requirements.
Detailed Design
This presentation will not discuss the detailed design process in depth because experience shows that the main issues seem to occur in the requirement analysis and planning phase. The following prerequisites need to be met:
Well defined requirements
Detailed system architecture design
Definition of domain requirements (SW, EE, ME…) based on the system requirements
Proper planning
Adequate staffing
10/26/2016 Disclosure or duplication without consent is prohibited 15
Integration and Test
Automotive SPICE provides 28 base practices and 25
outcomes for the right side of the ‘V’ model. If they are followed
correctly they guarantee minimal development churn since they
ensure that issues are found as soon as possible.
Prerequisites:
Requirements are testable
Traceability is ensured and verified
Resources are planned and available
10/26/2016 Disclosure or duplication without consent is prohibited 16
Summary
10/26/2016 Disclosure or duplication without consent is prohibited 17
Recommendations:
Use process model like CMMi or A-SPICE
Tailor the model to your organization
Pick a suitable ALM tool
Go from the system of systems to the system, then the sub
system and then the element
Plan your requirements processing and burn-down
Have risk and change management in place
Document and communicate your assumptions
Manage requirements churn
Enforce traceability and testing on the lower levels of the ‘V’
model
Plan and monitor your gate deliverables
How to eat the elephant?
Very carefully and one bite at a time!
