Automotive

Functional
Safety
Compliance

Automotive development trends:

Increasing standards and
complexity
The future is greener, quieter and all electric, making city living more attractive. Increasingly dense
urban environments where private-car ownership is discouraged through tightening regulation and
taxes on ownership. Conseqently, consumer preferences and Mobility behavior is changing, to a
multimodal public transportation and car sharing model as road infrastructure fails to keep up with
the number of vehicles on the road, resulting in gridlocked cities. In 2015, on one hand we saw an
all-time record in vehicle sales (cars and trucks) fueled by a recovering economy and cheap gas in
the US. On the other hand, in the US, one of the most car entric countries in the world, the number of
driving license holders amongst the young (16-24) fell in 2015. Disruptive forces are at play redefining
the auto industry, market trends that can be seen today at the end of 2016. So what are these trends?

Automotive Industry Megatrend:

Increasing software complexity
IoT technology is revolutionizing the automotive industry, turning auto manufacturers into software
developers now that all of the major automotive manufacturers have created connected car
departments. New car features are increasingly provided by Tier 1 automotive suppliers, semiconductor manufacturers providing more than just silicon chips, packaging software with hardware
as products, such as the Advanced Driver Assisted System (ADA) or Automotive System-on-chip
(SoC). The term IoT in the automotive industry (2016) is used primarily in reference to advanced
infotainment systems and over the air updates (OTA) just as those carried out by Tesla in December
2013 to update their electrical charging system.
The future is mobility services operated by big brands that will personalize cars based on driver
settings enabling the hot swapping of vehicles. The rise of cloud storage provides the means
to take your music collection to any car, - exactly how you organized it. Car mirrors and driver
seats will adjust automatically according to user height and weight, Stored User model and make
user preferences will be sharable between vechicles of the same type or those with the same
standardized components, providing many of the benefits (creature comforts) of ownership without
the associated pitfalls of ownership such as vechicle maintenance costs, depreciation and garage
ownership. For carmakers what this means is the trend is towards standardization of components
between models, software written for electronic components would therefore be transferrable. For
the consumer perhaps the result is for more car rentals and leasing and less ownership. Here the cooperation of BMW + Sixt on the Drive Now scheme really sounds like a winner, all thats missing is
those automatic comfort settings and a switch to all electric vehicles to keep the cost per trip down,
making it cheaper to rent than own a car thereby making it mass market.

Telematics Services

ellig
Int

ence & Vi

s
u
a
li
z
a
t

n
io

ligence & Visua

l
e
li z
Int
at
a
t

Da

ta

n
io

Da

Infotainment Services
3

All round multipurpose vehicles will give Way to

Vehicles Fit for Purpose
Today the typical privately owned vehicle is for multipurpose use, for work, family trips and daily
shopping and this is unlikely to change, but the trend is moving away from multipurporse towards
vehicles geared specific needs, fit-for-purpose. For city living this can be seen in the increase in
small hybrid cars sales and electric vehicles, an accelerating trend as the technology matures
and unit prices fall. Vehicle specialization will require auto manufacturers to manage an everincreasing range and variety of components to meet the needs of an increasing pool of target
groups. Customization requirements are only possible through modularization of components and
specialization of suppliers.

Electric cars are now in fashion, sexy

Everyone wants an electric car, especially if it can do zero-60 in 2 seconds and it looks like a Tesla.
The idea of never having to buy gas again is extremely attractive, especially if it has a good range
(250km +). Attitudes toward electric cars are changing, they are now desirable. Post emissions
scandal, VW has committed its future to the electric car, VW brand chief Herbert Diess stated that
By 2025 we plan to sell one million electric cars per year, and by then we also want to be the global
market leader in electro-mobility. This figure equates to approximately 25% of all cars sold by VW
in a year (2015 figures).

Autonomous Cars on the Road

What all the above trends point towards is greater user comfort and convenience, - what greater
comfort is there than being driven instead of being the one doing the driving? Most large automakers
have already declared their investment into an autonomous vehicle. Indeed many have already
started testing autonomous concept cars on the road.
Despite there being plenty of evidence that autonomous cars are far safer than human driven
ones, there is still a understandable fear of losing control, that feeling that makes most of us back
seat drivers. All electric takes the combustibility out of driving making self-driving cars just a little
less scary and crazy; however, there is still a long way to go before the idea has broad appeal.
Perhaps if you can imagine the BMW Sixt, Drive Now Scheme (mentioned above) but with all electric
autonomous cars of tomorrow that come to you within a couple of minutes at the order from a smart
phone app (no haggling with taxi drivers) you might be persuaded.

Increasingly Strict Standards for

Automotive Software Development
Responsibility for driving has to be placed somewhere, in the case of an autonomous car if there is
no driver then it must be on the software driving the car. Recent cases of software bugs (i.e. Toyota
Infotainment system failure) and IoT car hacks have put car software safety and security firmly in the
limelight. To counter the alarming nature of these cases and to protect and reassure consumers,
safety standards must be improved. To this end, the Spy Car legislation was proposed in the United
States although not much seems to have come from it in the last year or so. As to the wider question
of Automotive Software Development, there is already strict standards in place that we will look at in
the rest of this document.

Compliance and quality challenges

automotive manufacturers face
Multi- TIER Ecosystem
In an age of DevOps, Internet of things (IoT) and over the air updates (OTA) Automotive manufacturers
face a huge challenge in meeting the insatiable demand of consumers for new features. To meet these
consumer demands automotive manufacturers are increasingly reliant on an ever-expanding supply
chain, while Tier 1 suppliers provide the products (parts of the car) it is Tier 2 and Tier 3 suppliers where
the greatest growth has been, they have experienced exponential growth worldwide during the last 40
years or so. Tier 2 often competes with Tier 1 for business and so often Tier 2 become Tier 1 over time
if they are successful and grow. Tier 3 supply raw materials to Tier 2 suppliers who manufacture auto
components. They in turn sell their components to Tier 1 automotive parts manufacturers who use
such parts to create and sell finished products to auto manufacturers as well as to spares retailers.

Automotive manufacturers are therefore referred to as Original Equipment Manufacturers (OEMs). It

is important to note that Tier 1 suppliers typically supply more than one OEM and OEMs typically use
multiple Tier 1 suppliers for the same or similar product to ensure capacity and redundancy. Only
in this way can the automotive supply chain be considered lean and Agile enough for Just-in-time
(JIT) assembly. The trend is for more and more hardware products to include embedded electronics
with software updates providing new features, consequently it is becoming increasingly difficult to
manage the complex software ecosystem of a modern car. Software is being packaged up with
hardware components as products in their own right, for example, the Advanced Driver Assisted
System (ADA) or Automotive System-on-chip (SoC), the consequence is ever expanding software
ecosystem and code complexity, increasing risk for manufacturers as OEMs, relying on software
from external providers.
Standards such as ISO 26262 should ensure that every component of a car meets functional safety
requirements. It falls to the OEM to vet suppliers to ensure compliance with ISO 26262 and other
automotive standards, consequently collaboration between automaker and its suppliers is essential.
To comply with ISO 26262 both OEMs and automotive suppliers (no matter the tier), must adopt the
risk based approach to determining risk classes. This requires that potential hazardous operational
situations be qualitatively assessed and appropriate safety measures defined to detect, prevent and
mitigate those defined risks should they occur. Functional safety features are required in every phase
of automotive development, where these features are required are points of potential life threatening
product failure. When failure does occur, unnecessary complexity often has a part to play in the
failure, and often caused by the lack of interoperability between components. The joint US / EU
effort to harmonize standards and create a unified programming language for all car components
provides hope for the future, however there is still a long way to go before the end goal of complete
interoperability can be met.

Collaboration internally and with

the suppliers
As global entities Automotive manufacturers have facilities dispersed across the world, consequently
effective internal collaboration is essential to operate efficiently. Often multiple departments in different
locations are engaged in automotive software development, therefore a global overview of all software
development work is needed as well as a way for different teams to collaborate where there are
similarities between products.

codeBeamer ALM Software solves many of the challenges of collaborating in large development
teams and between different teams, providing complete traceability and transparency on the whole
lifecycle of software products.
Integrated ALM is the only solution for complete traceability starting from requirements, through test
and QA processes until final approval and deployment. Access via the web interface to real-time data
ensures access to all users across many departments can obtain up-to-date insights into status of
task, process and release.
Everything is traced across the entire application development lifecycle ensuring all artifacts can be
found. When baselines are created, a snapshot of the state of the project is taken at that particular
moment in time that can then be reverted to if it proves to be necessary. For example, in the case of a
bug introduced in a recent baseline, codeBeamer would enable the user to revert to the previous state
pre-bug.

Risk management and

hazard analysis
The primary action car manufacturers can take to manage risk in development is to vet all suppliers
carefully (using appropriate maturity model), insuring they not only implement ISO 26262 but also
maintain its use for the long term throughout the supply chain.

To maintain ISO 26262 integrity ongoing regular checks must be made to ensure compliance with
its methods and processes, the majority of which specifically relate to risk management and hazard
analysis. It is in the best interest of car manufacturers to make ISO 26262 a prerequisite to achieving
the supplier status in the first place because when all is said and done automakers, as (original
equipment manufacturers) OEMs are ultimately responsible for all component parts of vehicles sold,
including those supplied by 3rd parties. Any failure in a component (including software) provided by
an automotive supplier makes the OEM in question liable for damages associated with that fault.

How does ISO 26262 manage risk?

The standard ISO 26262 defines risk classes called Automotive Safety Integrity Levels (ASILs), these
levels enable automotive parts suppliers and automakers to classify the acceptable residual risk for
each subsystem of any electrical component as well as providing an acceptable general level of risk.
There are five ASIL levels (A-D, Lowest to highest) and each is determined by three major factors
during the first stage of development process. The contributing factors are :

The probability
of the hazardous
event

Detectability and
Controllability of
the hazard

The severity or
impact of the
hazardous event

Aside from defining the ASIL levels, ISO 26262 clearly lays out the requirements of each level,
necessary to mitigate or reduce risk as well as the test requirements for each ASIL level.

Failure Mode and Effects Analysis (FMEA)

As one of the most widely used methods for identifying potential failure modes (risk) and determine
the likelihood of occurrence, as well as detectability and controllability, FMEA is an essential tool
for ISO 26262 compliance, guiding the risk mitigation action necessary to meet the required ASIL.
Safety features of auto components mitigate the associated risks.
The assigned ASIL level for any given component acts as a target to meet during development, a
required safety level which when achieved provides an acceptable level of risk.

Likelihood

Severity

Requirements management
in embedded development
environment
Businesses in the high technology space typically use embedded development and rely on a high
speed of innovation to remain competitive. To maintain innovative development and retain the title
of innovative, customer feedback inclusion is key to establish what should come next, what potential
features should be evaluated and converted into requirements.

After product demands are analyzed, selected and prioritized to be converted into requirements
(Demand Management) they must be documented as requirements throughout the entire
development lifecycle, typically this task is assisted by requirements management software or
module of ALM, software that as part of its core functionality is a documents management tool. The
purpose of requirements management is to validate that the features of the product and that they
meet the needs of the customer and all stakeholders, this is done by constantly testing the product
against the constantly changing requirements throughout development.

Why DevOps?
DevOps breaks down the barriers between development and operations, thereby facilitating a freer
flow of feedback directly to the development team, speeding up feature and enhancement request
and response. To achieve this at scale, ALM Software features such as integrated service desk,
demand management and requirements management features are necessary. Continuous testing
and integration and delivery are all integral parts of DevOps.
DevOps breaks down the barriers between development and operations facilitating a freer flow
of feedback directly to the development team, including feature and enhancement requests. To
achieve this at scale, ALM Software features such as integrated service desk, demand management
and requirements management features are necessary. Continuous testing and integration and
delivery are all integral parts of DevOps.

Variants management
One of the major challenges of automotive manufacturers is to plan and develop complex products
and offer a variety of product variants. Engineers of automotive manufacturers have to be sure that the
parts they design should fit to several types of vehicles or they have to create several variants to meet
customers requirements. Variant management is about defining what should be standard and what
should be offered as variants.

Automotive manufacturers have two common problems:

To keep the
cost for
variation
low

To manage
the increasing
numbers of
variants

It requires automotive manufacturers to implement new methods to manage the increasing numbers
of variants in order to meet customers requirements. Automotive manufacturers often develop
algorithms from artificial intelligence to help engineers to add another part variant.
Efficiently managing multiple product variants in a product line can be a challenge. Re-using artifacts
gives you a chance to greatly accelerate development. This helps reduce your products time to
market while maintaining their high quality.
If you want to be competitive and differentiated from your competitors, we recommend looking at our
Variants Management feature that enables you to target multiple segments of a fragmented market
without having to worry about redundant work or quality issues.

10

codeBeamer ALM Variants Management feature in a nutshell

1
Define feature
models
(mandatory,
optional,
alternative,
other)

2
Store and
manage all
features of your
entire product
line

5
Create Variants
Specification
Documents
including
features for
each product
variant

3
4
Create Master
Specification
Documents
containing all the
components and
artifacts

Define the
relationships
between your
features

6
Re-use features,
specifications
and artifacts for
further product
variants

Maintain endto-end (bidirectional)

traceability
throughout the
development
lifecycle

See how to define features, variants, and manage

& oversee the development of each product variant
from requirements all the way to release:
codeBeamer ALM Variants Management
11

Standardization and Regulatory

issues: Functional Safety
compliance for ISO 26262,
Automotive SPICE and CMMI
standards
The automotive industry is heavily regulated with many international standards to adhere to, every part
of a new vehicle is rigorously tested against its defined purpose (tested against requirements) to ensure
it meets the expected quality and safety standards. This is vital for everyone concerned to be able to
prevent accidents, ensure vehicle occupant safety and security, and establish cause when accidents do
occur and a way to determine culpability when parts fail, thereby enable all parties to be insured against
damage.

For electrical component manufacturers looking to break into the automotive industry, adherance
to strict international automotive standards. These standards ensure functional safety features are
applied where necessary in every stage of development and are a prerequisite to becoming an
automotive supplier.
The standards required vary depending upon the components supplied. For example, a semiconductor
manufacturer wishing to supply the automotive electronics market in Europe would first need to be
qualified by the Automotive Electronics Councils AEC Q100 standard, this checks that component
stress testing practice of the manufacturer is up to an acceptable standard.
ISO 26262 is a risk-based safety standard, where the risk of hazardous operational situations is
qualitatively assessed and safety measures are defined to avoid or control systematic failures and to
detect or control random hardware failures, or mitigate their effects.
All suppliers of components to automotive manufacturers must also abide by a strict automotive
safety lifecycle (management, development, production, operation, service, decommissioning) as
specified by ISO 26262.
The standard also covers functional safety aspects of the entire development process of every
component, applying an automotive specific risk based approach to determining the level
of risk of potentially hazardous operational situations related to electrical or electronic systems
(Automotive safety Integrity levels ASILs A-D define + classifies risk levels). ASILs enables automotive
manufacturer to determine if the items necessary safety requirements are achieving an acceptable
residual risk.
Aside from the international standards, automotive suppliers must also meet the requirements of
automotive manufacturers.

12

Automotive manufacturers use maturity models to assess and qualify suppliers with respect to the
suitability of methods and processes used, these are some of the factors that determine supplier
capability. Typically either CMMI or Automotive SPICE (adapted from IEC 61508 to be Automotive
Industry specific) maturity models are used, although it is common for suppliers to deal with both.
CMMI is by far the most popular maturity model in the United States, while Automotive SPICE being
is the preferred model in Europe.
Capability Maturity Model Integration (CMMI) is a process improvement and appraisal program
implemented by Carnegie Mellon University. Many European and American customers require the
certified level of Capability Maturity. It is especially required in governmental environment and in the
case of any larger software development projects where SMEs can be involved as suppliers. CMMI
has five different maturity levels. Levels 4 and 5 is more dedicated to large organizations but CMMI
Level 2 and 3 can be easily achieved by smaller organizations.
The main benefits of CMMI is that it helps you to be compliant with large companies or government
tenders, improve the quality of your product and to deliver in time and budget. The main disadvantages
of CMMI are that it might generate additional overheads, higher costs, and less Agile processes.
Since 2005 when the Automotive SPICE model was published, many car manufactures have
adopted ASPICE to evaluate both software and electronics suppliers.
The Automotive SPICE standard is derived from the new ISO 15504 International Standard (IS) for
software process assessments. It has two dimensions, - the process dimension and the process
capability dimension.
The processes dimension is based on the ISO 12207 but it has been modified with automotivespecific extensions. The process capability dimension meet the six process capability levels as they
are defined in the ISO 15504.
It has a 5 level Capability Level Dimension. The first (0) level means that not all processes are
executed. Level 1 means that you can access to all important documents. Level 2 means that
everything is systematically planned and tracked. If you are at Level 3, you have uniform guidelines
for the complete organization. In Levels 4 and 5 the processes are statistically measured and
optimized.

13

Competitive Advantage:
Lean concept in Software
development
The lean thinking is not a new concept; it started at the beginning of the 20th century. Toyota modified
the original lean concept in the mid-70s and they created the Toyota Production System (TPS). TPS was
focusing on manufacturing and logistics for the automobile manufacturer, including interaction with
suppliers and customers.

The focus of the lean concept is to reduce waste, meaning any time and effort that does not generate
value for business. However, some redundancy is important to keep your business running. Lean
software development was created to apply lean principles for IT projects.
Lean software development (LSD) means the adoption of lean manufacturing and lean IT principles
and practices to the software development. The key principles of lean software development are as
follow:

1
Eliminate waste
reduce unnecessary
code or functionality,
bureaucracy, defects
and quality issues

4
Defer
commitment

2
Build quality

6
Respect people

3
Create knowledge

7
Optimize the whole

5
Deliver fast

14

Values of using Agility across the Lifecycle

Agile software development is often discussed as the part of lean software development concept.
Iterative and incremental development are key practices in Agile development methodologies. The iterative
process of learning and continual improvement is an important part of identifying waste and eliminating it.

Scrum and Kanban: Optimize work and collaboration

Scrum and Kanban are the two most widely known and used Agile methodology.
Scrum is a well-defined process framework. Scrum prescribes the use of short fixed-length
iterations with potentially shippable code demonstrated after each iteration referred to as sprints
in Scrum terminology. These sprints are the basic units of work for the cross-functional and selforganizing teams that Scrum advises its users to set up.
A prioritized product backlog is used to collect the requirements in the form of user stories. The
sprint backlog draws upon the product backlog, and is set up during the sprint-planning meeting.
Iteration planning and sprint review meetings, as well as daily stand-up meetings help the team stay
focused and aligned to goals, and enable them to incorporate customer feedback in the process of
development after each iteration.
Kanban can be simply summarized and defined as a visual process management system. It is not a
process framework, but rather a tool that helps introduce the idea of incremental improvement.
With Kanban you can visualize workflow by splitting the work into pieces, writing each item on a card
and putting it on the wall. It uses named columns (to-do, in progress and done) to illustrate where
each item is in the workflow. Limiting Work In Progress (WIP) helps to explicitly limit how many items
may be in each workflow state. Kanban is a great tool to better manage resources.
It may not be obvious at first for those not familiar with these two techniques, but while Scrum and
Kanban are different techniques sharing the same fundamental goals and values, they do not rule
out each other. In fact, many teams choose to combine both in their development efforts, leading to
a method referred to as Scrumban.
Initial release planning determines what product requirements listed in the product backlog should
be prioritized and entered into the release backlog. Agile Release Planning of codeBeamer ALM
provides you with a friendly dashboard to manage sprint and release planning. You can assign items
to backlogs and sprints or move items between sprints by using the drag & drop function. It also
allows you to assign work items to project members or teams. Changes to work items can be made
without leaving the planning board.

15

Requirements-based tests & Automated testing: Improve traceability

and reliability
In requirements-based tests, requirements are essential input for testing. Testing often starts with
the project requirements used during development. In Requirements-based tests, test cases are
designed based on test objectives and test conditions that are derived from requirements.
If the requirements are poorly defined, or not defined as well as is desirable, the requirements-based
tests cannot be better than the requirements that are included in the testing.
The goals of Requirements-based tests are:

1
Validate that the requirements are
correct, complete, unambiguous, logically
consistent, and testable.

2
Create necessary and sufficient (from
a black box perspective) set of test
cases from the requirements to ensure
that the design and code fully meet the
requirements. It means reducing the
immensely large number of potential tests
down a reasonable size set of tests.

It is important that testing must be carried out in a timely manner. The testing process should add
value to the software life cycle, hence it needs to be effective, and the testing must provide the
overall status of the project, hence it should be manageable.
The advantages of requirements-based tests are that using this method provides information
about the coverage of requirements with tests, and about how much the system implements these
requirements. It is also easy to follow the testing of the different features, if the input of the test plan
is the requirement specification. In other words, you test exactly what the software functionality in
question is supposed to do, and nothing else.
Deriving test cases and collecting coverage information, starting from requirements is a
straightforward process that is also an advantage of this method. Analyzing test coverage helps your
understand what percentage of your requirements have been covered by successful test cases, or
how thorough your testing activities were.
Automated testing is meant for large projects with many system users. If you start with automated
testing, your automated testing tool will run the tests according to predefined requirements. Once
the requirements and the outcomes align, you have a bug-free product. If they do not, you have to
alter your code and run tests again until that happens.

16

The Value of the Automated

Testing

Downside of Automated Testing:

Increase in up-front investment

Saving time and catching bugs before

release: Manually repeated tests are often
considered to be costly and time consuming.
Once an automated test is created, it can run
repeatedly, continuously at no additional cost.
Once you start with automated testing, you do
not have to waste manual effort on complex
testing such as exploratory testing. Automated
tests can be run continuously and at any time.
By running tests regularly, you can catch bugs
in your tests or code quickly (ideally before
release).

The Time You Have to Invest into Automated

Testing: As mentioned above, automated
testing will save you time once it is done.
However, writing automated tests will take
approx. 30% more time. Automated testing is
an investment that will save you money over
time.

Faster feedback on changes: Automated

testing provides testers with faster feedback on
regressions. Faster feedback enables software
developers to trace back what went wrong or to
make necessary changes without ruining the
existing work.
Test expenses: Once an automatic test is
written, a computer can run it at very low cost.
The same manual test would require a person
to work on a list of instructions and it would
cost much more.
Test reliability: Even the more experienced
software developers and testers can and
do make mistakes, herein lies the problem;
mistakes by developers or in testing by humans
are hard to detect. With automated testing if a
problem is detected it is recorded automatically
or the test is stopped as long as the computer
will execute the same testing process, every
time. The Failure Mode and Effects Analysis
(FMEA) is a great technique for failure analysis.
Once a problem occurs, the test reports stops
appearing and the result is a false test result. It
will not happen if the tester misses a step and
ticks the OK button. Automated testing often
highlights when someone has forgotten to check
in code, that also ensures better test reliability.

Poorly designed test suite and re-testing

expenses: Another cost factor for automated
testing is the design. If the test suite is poorly
designed, adding new tests might cost more
than the value provided by the test suite.
Unreliable Tests Come with Additional
Expenses: If the test is unreliable, time needs
to be invested to find the cause, was it caused
by regression or via the test code? It also
means that manual tests need to be introduced
into the workflow, that comes with extra costs
and the wasting the time of developers and
testers.
Automated Testing Tools Have Limits: Many
automated testing tools cannot test image
colour or font size. Their changes can be only
detected by manual testing.

17

DevOps and ITIL: Increase IT services and manage business risks

DevOps means that developers and operators are working together closely on making sure the
product is reliable, and that as any potential issues are covered as reasonably possible. DevOps can
be thought of as an approach, culture, as well as a set of values and principles, but it also consists of
several tools, methods and practices that are instrumental to implementing this combined approach.
With Agile placing emphasis on the end users expectations and experience of the product (what
users actually want), developers have naturally started prioritizing these aspects of development,
incorporating the quality assurance and operations approaches in their work.
As such, this tight alignment between Dev and Ops (and QA that is traditionally in between
them, as a responsibility of the operations team) can be regarded as an extension to Agile, which
encourages close collaboration of all stakeholders during and following development. DevOps
simply extends this to the part in the SDLC that follows delivery. Thus, the basic values that drive the
DevOps approach can generally be considered similar to Agiles principles.
The merging of development and operations brings together formerly separate roles and teams,
aligning their objectives. Traditionally, the development team aimed to include as many amazing
features in the product as possible, while the operations team wanted to make sure the system was
reliable and stable at all times. With DevOps, they share the goal of delivering a dependable piece of
software that perfectly fits the requirements of the user with the Agile terminology, we could simply
call this working software.
Similarly to Agile, DevOps should be more than just the implementation of practices or tools in a
process while using adequate methods and tools certainly helps, DevOps means the adoption of
the above values and principles. The means to support these principles are secondary to adopting
the concept itself on a cultural level.
The benefits offered by employing the DevOps approach throughout the software development
lifecycle include:

More frequent releases / deployment (faster time to market)

Lower chance of product failure once deployed (stability)
Faster time to recovery after unexpected events
Increased efficiency through automation
Maintainability (and scalability) of Ops processes.

18

ITIL (Information Technology Infrastructure Library) is a set of ITSM practices. It focuses on

aligning IT services with the needs of business. While TIL is flexible and scalable, organizations
of all sizes can implement parts of ITIL to deliver business benefits. ITIL was developed to
help organizations to focus on the needs of the customers and user experience rather than
focusing on the technology. By using proven standard, you can easier deliver agreed service
and the support team can faster restore service and reduce downtime.
Adopting successfullyITIL bring you the following benefits:

Improve
IT services
Reduce
support
expenses
Increase
customers
satisfaction
Deliver service
that meets
customers
requirements
Manage business
risks and service
failure from
unplanned changes

19

It is often a question if ISO20000 and DevOps can be used together

To answer the above question, firstly we must look at what ISO 20000 is and look at how DevOps
addresses ITSM.
ISO 20000 was the first international standard for IT Services Management, its aim was to provide
proof of service, that the organization in question is working to ITIL recommendations for ITSM,
which is primarily composed of Escalation management. Proof comes in the form of ITSM ISO20000
certification for Managers. What ISO20000 does not provide is specific advice on how to design
your ITSM process.
As an offshoot of Agile, DevOps is still in its infancy and therefore NOT well defined, it does not
have a precise set of practices or processes neither prescriptive nor descriptive; and yet DevOps
is one inevitable stop on a journey towards the end Agile destination which is the Agile Enterprise.
The DevOps mantra is to break down the barriers between Development and IT Operations by
streamlining and integrating practices and processes.
From these brief descriptions it can be seen that this is not an either and or question, if anything ISO
20000 should be seen as assisting with DevOps implementation when ISO 20000 processes are
designed with integration for DevOps in mind. After all a DevOps integrated approach to ITSM can
also be ISO 20000 certificated. Beyond ISO 20000 to the broader knowledge base of ITIL and as to
whether it is needed in an DevOps enterprise, is an entirely different question.
If youre looking for a how to guide for implementing ISO 20000 and DevOps together, then you
need to look to the Scaled Agile Framework.

A framework for DevOps The Scaled Agile Framework (SAFe)

The Scaled Agile framework is a freely available knowledge base for scaling Agile for enterprise
use. It is also suitable for the concept of DevOps. The SAFe model extends Agile for use by IT
Operations and it does so in a highly prescriptive manner. Therefore, SAFe provides the how-toguide for integrating ISO 20000 into DevOps for large-scale enterprise use.
Agile ALM software such as our own codeBeamer ALM not only provides the features necessary for
implementing SAFe at enterprise level, but also provides the means by which ITSM and Development
processes can be integrated. codeBeamer ALM also comes with an integrated service desk and
escalation management system integrated within the application lifecycle that also meets the
requirements of ISO 20000.

20

codeBeamer ALM
Automotive Template
The growing complexity and the increasing focus on traceability and safety emphasizes the need
of embedded electronics and software in modern vehicles. Complexity brings risks that has to be
minimized or mitigated using specific risk management processes.

Standards and regulations ensure the safety and reliability of automotive industry products.
Adherance to all industry regulations is not optional, but rather a prerequisite of automotive
development. Compliance audits are common and failure of compliance subject to harsh penalties.
Our ISO 26262 Template leverages the capabilities of codeBeamer ALM to help cut development
time and costs while ensuring high product quality. Its ability to implement mature processes
enables you to comply with automotive standards and guidelines.
Our Automotive template assists automotive manufacturers to develop safety-related
embedded systems up to ASIL D or SIL 3 while complying with functional safety requirements of
models(standards)suchas Automotive SPICE andCMMI.
Using our Automotive template helps you to achieve gapless traceability from requirements to
release, rigorous process control, security, and process workflow features. It provides electronic
records and e-signatures, advanced risk management, quality assurance, and reporting features.
Our Automotive template assists you to comply with IEC 61508 and ISO 26262, adhere to the
Automotive SPICE and CMMI models, and overall enable you to develop safety-related embedded
systems up to ASIL D or SIL 3.

Advantages of using our codeBeamer Automotive template

less time of on-boarding/implementation

more understandable trainings

domain oriented is already available

easier, quicker roll out

common understanding of expected results

See how codeBeamer ALM and our Automotive template supports your Automotive Development
and Regulatory Compliance with ISO 26262, IEC 61508, Automotive SPICE, CMMI and much more.

21

codeBeamer ALM is
qualified for ISO 26262 /
IEC 61508
Safety-critical industries such as automotive, medical and aviation
are regulated by serious standards to ensure safety and security. The
standards are usually difficult to interpret, and implementing measures to
comply with their requirements is a challenge.

With increasing product complexity, companies are struggling to maintain traceability, adequate risk
management, process enforcement, and documentation throughout the lifecycle in order to achieve
compliance with relevant standards. Using certified tools to support compliance is not only greatly
helpful, but is quickly becoming indispensable in the development of high quality products with
functional safety requirements.
It is often difficult for customers to differentiate between our product and the various other options on
the marketplace.

The Value of the TV Certification

The qualification of TV Nord proves that codeBeamer ALM meets critical functional safety
requirements as per the guidelines of the general safety standard IEC 61508, and its derivative ISO
26262 for automotive systems development.

Benefits of working with codeBeamer ALM certified by TV Nord:

Demonstrates compliance with legal requirements
Competitive advantage through prequalification
Reduce liability to risk by demonstrating safety standards
Accelerate audit times
Save time and money on tool qualification
The TV Nord qualification provides the evidence that codeBeamers development processes comply
with the most demanding Automotive Safety Integrity Level (ASIL-D) as defined in ISO 26262, and
IEC 61508 up to SIL3, demonstrating that codeBeamer can reliably implement and replicate the
processes.
Furthermore, any software and hardware systems developed using codeBeamers software
development processes is also considered to meet the functional safety requirements of ISO 26262;
benefiting our users considerably by nearly eliminating compliance effort altogether.

22

To request Intlands Automotive ISO 26262 Template, please fill in this form:
https://intland.com/automotive-software-engineering/
Or simply reach out to us for a live 1-on-1 product demonstration:
sales@intland.com
If youd rather get acquainted with the advanced features and capabilities of
codeBeamer first, why not start your free 30-day trial today?
https://intland.com/download-codebeamer/