The new UNECE WP.29 regulation and ISO/SAE 21434 standard on cybersecurity is set to
trigger a paradigm shift in the automotive industry. The impact of this regulation and standards
will be felt across the entire automotive supply chain as both OEMs and their suppliers will need
to comply with these new regulations.
One of the most critical activities recommended by the ISO/SAE 21434 standard for
cybersecurity is Threat analysis and Risk Assessment (TARA) to determine the extent to which
a road user can be impacted by a threat scenario
Join us to hear how IBM Engineering Automotive Compliance solution enables methods and
work products by ISO/SAE 21434 for Threat Analysis and Risk Assessment(TARA) in 7
systemic steps.

The Engineering Test Management Solution will help with prioritizing your test effort, improving your traceability, and assisting with the decision - Are we ready to ship?
In this session, we will learn about the new features in ETM 7.0.3 from the Word/Excel importer, Web UI, and Usability enhancements, to Simplified linking and much more to help drive your testing effort. Join us!

A few years ago, IBM introduced the concept of Global Configuration Management (GCM) to its Collaborative Lifecycle Management (CLM) suite of integrated tools. This was a game changer for requirements management. It was not only possible to put requirements under configuration management, but it was possible to save collections of corresponding requirement, test, workflow, source, and model artifacts in a single configuration.
During this presentation we will build the case for component-based requirements management, illustrate Global Configuration Management concepts, and focus on various Component Usage Patterns within the context of GCM 7.0.2 and IBM’s Engineering Lifecycle (ELM) suite of tools.
After registering, you will receive a confirmation email containing information about joining the webinar.

Virtually all systems engineering is performed in the context of a product line – a family
of similar systems with variations in features and functions. Hardly anyone builds just
one edition, just one flavor, just one point solution of anything. When presented with
this hypothesis, the initial reaction from systems engineers is often disagreement.
However, when pressed for examples where organizations build a complex system
without deriving from an existing similar system and without the intent of building
other similar systems, examples are not readily forthcoming.

Because of the inherent assumption in the system engineering community that systems
engineering is primarily a methodology for building a single system, systems
engineering methods and tools have traditionally focused on how to build the
individual point solutions within a family rather than how to engineer a system family
as a whole. This mismatch comes with significant risks. A recent study by the analyst
firm Tech-Clarity, involving surveys of nearly 200 company leaders engineering
products and systems, the number of product and system configurations is largely
viewed as the top and growing source of complexity, which results in one of their top
two business challenges. Engineering complexity slows progress and leads to defects,
errors, and omissions, which in turn leads to the business risks of delays, budget
overruns, recalls, system failures, and opportunity losses.

When systems in a system family are engineered as individual point solutions,
techniques such as clone-and-own, branch-and-merge, and reuse repositories result in
ever-growing duplicate and divergent engineering effort. Trying to manage the system
family commonality and variation among these individually engineered systems relies
on tribal knowledge and high bandwidth, error-prone interpersonal and document-
based communication among different subject matter experts. Furthermore, when each
engineering discipline adopts a different ad hoc technique for managing variations
among the members of the system family, the result is error prone dissonance when
trying to translate and communicate across the lifecycle.

This webinar presents a surrogate model approach to advance fundamental research on understanding impacts of
engineering decision-making on complex system performance and system development cycle times. The approach is
motivated by digital transformation and advancement of the digital engineering strategy by the U.S. Department of
Defense as part of acquisition modernization. The digital engineering strategy focuses on five goals as a means to
reduce acquisition cycle times and increase capability deployment to the warfighter, but we lack the theory to
understand the impact of the digital transformation on engineering processes, decision- making and the solution
performance. The surrogate model approach discussed herein could provide a methodology for studying the impact of
digital engineering on solution performance and lifecycle development time on a wide class of design problems with
tunable complexity.

Engineers may find themselves in an organization which does not value systems engineering, or worse, in an organization which is hostile to systems engineering practices.
The purpose of this presentation (and the paper on which it is based) is to help such engineers do effective systems engineering despite the lack of support. We offer a description of the variation found in top management beliefs and engineering cultures to aid in a diagnosis of the workplace environment. We then offer suggestions for appropriate actions suitable to each combination of top
management belief and cultural support or hindrance for systems engineering practices. These actions may help individual engineers to implement effective systems engineering despite
hindrances from the organizational culture or top management.

Several case studies are included to illustrate how the approaches described have been implemented from the authors' own experience.

Don't miss this opportunity to hear how others are cultivating SAFe beyond IT and building real business agility!

In this presentation You will learn about the latest version of IBM Common Licensing:
o Review what are the key differences between Rational License Key Server (RLKS) 8.1.6 and
IBM Common Licensing License Server v9
o Discuss what is needed to implement ICL and what is optional
o Discuss Supported and Non-Supported uses of ICL and workarounds
o Review the system requirements needed to implement ICL and discuss the iFix strategy.