Skip to content

Commit 9530a45

Browse files
jasonrandrewsjasonrandrews
authored
Merge pull request #3423 from anupras-mohapatra-arm/summaries-and-faqs
First batch of summaries and FAQs added to Automotive LPs + edit to Rafay summary
2 parents a628cda + 0168fc2 commit 9530a45

5 files changed

Lines changed: 191 additions & 7 deletions

File tree

‎content/learning-paths/automotive/openadkit1_container/_index.md‎

Lines changed: 42 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,9 +15,50 @@ prerequisites:
1515
- An Arm Neoverse cloud instance, or a local Arm Neoverse Linux computer with at least 16 CPUs and 32GB of RAM
1616
- Familiarity with Docker and Docker Compose
1717

18+
# START generated_summary_faq
19+
generated_summary_faq:
20+
template_version: summary-faq-v3
21+
generated_at: '2026-06-24T15:35:34Z'
22+
generator: ai
23+
ai_assisted: true
24+
ai_review_required: true
25+
model: gpt-5
26+
prompt_template: summary-faq-v3
27+
source_hash: 37913b2c4aed914d32dbdad054ebdd2b1d4587da3ede1a33ba81e3e68bf504a3
28+
summary_generated_at: '2026-06-24T15:35:34Z'
29+
summary_source_hash: 37913b2c4aed914d32dbdad054ebdd2b1d4587da3ede1a33ba81e3e68bf504a3
30+
faq_generated_at: '2026-06-24T15:35:34Z'
31+
faq_source_hash: 37913b2c4aed914d32dbdad054ebdd2b1d4587da3ede1a33ba81e3e68bf504a3
32+
summary: >-
33+
You'll deploy a containerized Autoware
34+
Open AD Kit simulation on Arm Neoverse using Docker and Docker Compose, within a SOAFEE-aligned Shift-Left workflow. First, you'll learn about software-defined vehicles (SDVs), SOAFEE, ROS 2, and the Open AD Kit components used in the demo. Then, you'll prepare an Arm Neoverse Linux system and use Docker Compose to start the Open AD Kit visualizer, planning, and simulation services. By the end, you'll review a running simulation. The workflow has been tested on both cloud (Amazon EC2) and on-premise Arm Neoverse platforms.
35+
faqs:
36+
- question: What result should I expect after launching the Docker Compose stack?
37+
answer: >-
38+
The visualizer service starts in detached mode, followed by continuously running planning
39+
and simulation services. Active containers for these components indicate the demo is operating
40+
as intended.
41+
- question: Where are the ROS 2 commands and service configurations defined?
42+
answer: >-
43+
They are defined in the docker/docker-compose.yml file. Reviewing that file shows the launch
44+
order, container settings, and ROS 2 commands used by the demo.
45+
- question: Can I run the same workflow on cloud and on-prem Arm Neoverse systems?
46+
answer: >-
47+
Yes. The worklow has been tested on Amazon EC2 and an Ampere Altra workstation, so you can
48+
choose either a cloud instance or an on-premise Arm Neoverse system.
49+
- question: What should I check before starting the demo to avoid resource-related failures?
50+
answer: >-
51+
Verify the Arm Neoverse system provides at least 16 CPUs and 32 GB of RAM. Ensure Docker
52+
and Docker Compose are installed and available.
53+
- question: If I stop and restart the demo, do I need to reconfigure anything?
54+
answer: >-
55+
No. Docker Compose allows you to start with the previous session’s settings without modifications,
56+
so the configuration persists between runs.
57+
# END generated_summary_faq
58+
1859
author: Odin Shen
1960

20-
generate_summary_faq: true
61+
generate_summary_faq: false
2162
rerun_summary: false
2263
rerun_faqs: false
2364

‎content/learning-paths/automotive/openadkit2_safetyisolation/_index.md‎

Lines changed: 56 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,11 +16,66 @@ prerequisites:
1616
- Completion of the [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) Learning Path
1717
- Basic familiarity with Docker
1818

19+
# START generated_summary_faq
20+
generated_summary_faq:
21+
template_version: summary-faq-v3
22+
generated_at: '2026-06-24T15:35:59Z'
23+
generator: ai
24+
ai_assisted: true
25+
ai_review_required: true
26+
model: gpt-5
27+
prompt_template: summary-faq-v3
28+
source_hash: 92a6dac2b1674a44cd623a0c8c3189b38438124a6067ed7ca776999ff1d8b5bf
29+
summary_generated_at: '2026-06-24T15:35:59Z'
30+
summary_source_hash: 92a6dac2b1674a44cd623a0c8c3189b38438124a6067ed7ca776999ff1d8b5bf
31+
faq_generated_at: '2026-06-24T15:35:59Z'
32+
faq_source_hash: 92a6dac2b1674a44cd623a0c8c3189b38438124a6067ed7ca776999ff1d8b5bf
33+
summary: >-
34+
You'll learn about prototyping safety‑critical isolation for autonomous
35+
driving workloads on Arm Neoverse by applying functional safety concepts, ISO 26262 and ASIL
36+
guidance, and a safety‑island architecture. First, you'll understand how to separate safety‑critical control
37+
logic from non‑safety functions. Then, you'll connect components using a publish‑subscribe model (DDS/ROS
38+
2) within containerized deployments or across Arm‑based instances. You'll explore lifecycle
39+
practices aligned with the V‑model, including clear requirements, version control, impact
40+
analysis, and regression testing. By the end, you'll organize simulation components into
41+
isolated units with defined interfaces and documentation suitable for advancing ISO 26262‑oriented
42+
development on Arm Neoverse.
43+
faqs:
44+
- question: How do I decide which components belong on the safety island versus the general
45+
ECU?
46+
answer: >-
47+
Place time‑critical, safety‑relevant control logic (for example, braking or steering) on
48+
the safety island, and keep non‑critical features (such as infotainment) on the general
49+
ECU. The goal is strong isolation, determinism, and minimized coupling for safety‑critical
50+
paths.
51+
- question: What should I verify to confirm the isolation boundaries are defined correctly?
52+
answer: >-
53+
Check that safety‑critical components run independently from non‑critical services and communicate
54+
only through defined publish‑subscribe interfaces. Ensure data exchanged is minimal and
55+
purpose‑specific so that safety logic is not impacted by unrelated functions.
56+
- question: How do ISO 26262 ASIL levels influence my development workflow in this prototype?
57+
answer: >-
58+
Higher ASIL targets require more rigorous processes and evidence across the V‑model. For
59+
example, ASIL‑D changes go through full impact analysis and regression testing to prevent
60+
introducing new risks.
61+
- question: Should I separate components using containers on one host or across multiple Arm
62+
Neoverse instances?
63+
answer: >-
64+
Both approaches support prototyping: containers model software isolation on one system,
65+
while multiple instances model stronger physical separation. Choose the option that best
66+
matches the isolation assumptions you want to evaluate.
67+
- question: What artifacts should I capture to support ISO 26262 traceability in this prototype?
68+
answer: >-
69+
Maintain clear safety requirements, rationale for the safety‑island split, defined DDS/ROS
70+
2 interfaces, and mapped tests to requirements. Record versioned changes, impact analyses,
71+
and verification results aligned to the V‑model stages.
72+
# END generated_summary_faq
73+
1974
author:
2075
- Odin Shen
2176
- Julien Jayat
2277

23-
generate_summary_faq: true
78+
generate_summary_faq: false
2479
rerun_summary: false
2580
rerun_faqs: false
2681

‎content/learning-paths/automotive/system76-auto/_index.md‎

Lines changed: 45 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,11 +12,54 @@ learning_objectives:
1212
- Build and run the Arm Automotive Solutions Software Reference Stack locally.
1313

1414
prerequisites:
15-
- A System76 Thelio Astra desktop computer running Ubuntu 24.04.
15+
- A System76 Thelio Astra desktop computer running Ubuntu 24.04.
16+
17+
# START generated_summary_faq
18+
generated_summary_faq:
19+
template_version: summary-faq-v3
20+
generated_at: '2026-06-24T15:36:29Z'
21+
generator: ai
22+
ai_assisted: true
23+
ai_review_required: true
24+
model: gpt-5
25+
prompt_template: summary-faq-v3
26+
source_hash: 2b758d2dcf28a683ab164e28578a736d6d730b81dfbc01a6765619052fcdebd0
27+
summary_generated_at: '2026-06-24T15:36:29Z'
28+
summary_source_hash: 2b758d2dcf28a683ab164e28578a736d6d730b81dfbc01a6765619052fcdebd0
29+
faq_generated_at: '2026-06-24T15:36:29Z'
30+
faq_source_hash: 2b758d2dcf28a683ab164e28578a736d6d730b81dfbc01a6765619052fcdebd0
31+
summary: >-
32+
You'll use a System76 Thelio Astra Arm desktop to build and run the
33+
Arm Automotive Solutions Software Reference Stack in a local Multipass virtual machine. You'll start by
34+
creating an Ubuntu 20.04 guest, isolating builds, and compiling Yocto-based
35+
components targeting a Fixed Virtual Platform that models the Arm Reference Design-1 AE. You'll review the Thelio Astra platform and the software stack context, then run a Parsec-enabled TLS demo that establishes an HTTPS session to transfer a web page.
36+
faqs:
37+
- question: Which Multipass install guide should I follow before creating the virtual machine?
38+
answer: >-
39+
Use the Multipass install guide for Arm Linux before starting the steps. This ensures Multipass
40+
is set up correctly on the Thelio Astra running Ubuntu.
41+
- question: Which Ubuntu release runs inside the Multipass virtual machine for this build?
42+
answer: >-
43+
The build is performed from the command line of an Ubuntu 20.04 Multipass virtual machine.
44+
- question: Why use a Multipass virtual machine on the Thelio Astra instead of building directly on the host?
45+
answer: >-
46+
A Multipass VM creates an isolated automotive development environment and lets you split
47+
the resources of the Thelio Astra between development tasks. It keeps the build and test
48+
process contained.
49+
- question: What target platform is used when running the software stack examples?
50+
answer: >-
51+
The examples run on a Fixed Virtual Platform that models the Arm Reference Design‑1 AE (RD‑1
52+
AE) hardware system.
53+
- question: What result should I expect from the Parsec-enabled TLS demo?
54+
answer: >-
55+
The demo establishes an HTTPS session and transfers a simple web page over a TLS connection.
56+
Parsec provides the common API to the underlying security and cryptographic services used
57+
by the demo.
58+
# END generated_summary_faq
1659

1760
author: Jason Andrews
1861

19-
generate_summary_faq: true
62+
generate_summary_faq: false
2063
rerun_summary: false
2164
rerun_faqs: false
2265

‎content/learning-paths/automotive/zenacssdebug/_index.md‎

Lines changed: 46 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,9 +18,54 @@ prerequisites:
1818
- Arm Development Studio 2024.1 or later with a valid license - for support see the [Install Guide for Arm DS](/install-guides/armds/)
1919
- Basic understanding of the Arm Zena CSS software stack, Armv8-A/Armv9-A cores, and Linux
2020

21+
# START generated_summary_faq
22+
generated_summary_faq:
23+
template_version: summary-faq-v3
24+
generated_at: '2026-06-24T15:37:11Z'
25+
generator: ai
26+
ai_assisted: true
27+
ai_review_required: true
28+
model: gpt-5
29+
prompt_template: summary-faq-v3
30+
source_hash: 74740788edbfe7ea09bf955455b4aeaed00e667fa8c9d68467353c1f64528b08
31+
summary_generated_at: '2026-06-24T15:37:11Z'
32+
summary_source_hash: 74740788edbfe7ea09bf955455b4aeaed00e667fa8c9d68467353c1f64528b08
33+
faq_generated_at: '2026-06-24T15:37:11Z'
34+
faq_source_hash: 74740788edbfe7ea09bf955455b4aeaed00e667fa8c9d68467353c1f64528b08
35+
summary: >-
36+
You'll debug the Arm Zena Compute Subsystem (CSS) reference
37+
software stack on a Fixed Virtual Platform using Arm Development Studio. First, you'll launch the
38+
FVP with the Iris debug server enabled, then create and save a custom Arm DS configuration. You'll establish connections
39+
to each heterogeneous component within Zena CSS to debug the Linux kernel and user processes. By the end, you'll create reusable `.launch`
40+
files, step through early RSE boot, and attach to Safety Island and Linux targets to inspect
41+
execution across the system.
42+
faqs:
43+
- question: Which FVP launch method should I use for debugging?
44+
answer: >-
45+
Use the launch invocation that enables the Iris debug server. The default build-environment
46+
command runs the stack but does not enable Iris, so Arm Development Studio cannot connect.
47+
- question: How should I organize and save my debug connections in Arm Development Studio?
48+
answer: >-
49+
Create a General Project to store the connection files and save each connection as a `.launch`
50+
file. This makes it easy to reuse and enhance configurations for each subsystem.
51+
- question: What is the expected workflow to debug the RSE from reset?
52+
answer: >-
53+
Start the FVP with Iris enabled and hold the model at reset, then connect from Arm Development
54+
Studio. Load Trusted Firmware‑M symbols and step through the early boot code.
55+
- question: Can I connect to all Zena CSS processors at the same time?
56+
answer: >-
57+
Yes. Arm Development Studio supports heterogeneous systems, so you can connect to the RSE,
58+
Safety Island, and primary compute cores simultaneously, though you might prefer to set up
59+
one connection fully before adding others.
60+
- question: Why isn’t there a predefined Zena CSS target in Arm Development Studio?
61+
answer: >-
62+
As of Arm Development Studio 2025.0, there is no out-of-the-box configuration for the Zena
63+
CSS FVP. Create one using the Iris interface as shown in the Learning Path.
64+
# END generated_summary_faq
65+
2166
author: Ronan Synnott
2267

23-
generate_summary_faq: true
68+
generate_summary_faq: false
2469
rerun_summary: false
2570
rerun_faqs: false
2671

‎content/learning-paths/servers-and-cloud-computing/rafay-eks/_index.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -34,9 +34,9 @@ generated_summary_faq:
3434
faq_generated_at: '2026-06-24T20:45:31Z'
3535
faq_source_hash: 76cbd5e4b3a61e9604e0df9b3ba2a5e5af4aa9a0c295ece3c4ee5a98ec365630
3636
summary: >-
37-
In this Learning Path, you'll provision an Amazon EKS cluster on Arm using
37+
You'll provision an Amazon EKS cluster on Arm using
3838
the Rafay Kubernetes Operations Platform and validate workloads on AWS Graviton-based nodes.
39-
You'll define a declarative cluster manifest in Rafay referencing an existing project,
39+
First, you'll define a declarative cluster manifest in Rafay referencing an existing project,
4040
blueprint, and cloud credential. Then, you'll create the EKS cluster and deploy NGINX pinned to arm64
4141
to confirm scheduling on Graviton-based instances. Finally, you'll remove the NGINX workload and deprovision the EKS resources to avoid ongoing cloud costs.
4242
faqs:

0 commit comments

Comments
 (0)