From 053315d243d114ad1002618a54ee2f1a36e4092e Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Mon, 21 Jul 2025 19:34:46 +0000 Subject: [PATCH 01/21] - Updated title to "Prototype safety-critical isolation for autonomous systems on Neoverse" for clarity and Microsoft Learn style - Rewrote learning objectives to use active voice, parallel structure, and more concise phrasing - Reworded prerequisites for consistency and clarity --- .../openadkit2_safetyisolation/_index.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md index 4319e4824a..54dc4c5a23 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md @@ -1,5 +1,5 @@ --- -title: Prototyping Safety-Critical Isolation for Autonomous Application on Neoverse +title: Prototype safety-critical isolation for autonomous systems on Neoverse draft: true cascade: @@ -10,14 +10,15 @@ minutes_to_complete: 60 who_is_this_for: This Learning Path targets advanced automotive software engineers developing safety-critical systems. It demonstrates how to use Arm Neoverse cloud infrastructure to accelerate ISO-26262 compliant software prototyping and testing workflows. learning_objectives: - - Learn the Functional Safety principles—including risk prevention, fault detection, and ASIL compliance—to design robust and certifiable automotive software systems. - - Understand how DDS enables low-latency, scalable, and fault-tolerant data communication for autonomous driving systems using a publish-subscribe architecture. - - Distributed Development for Functional Safety. Learn how to split the simulation platform into two independent units and leverage distributed development architecture to ensure functional safety. + - Apply Functional Safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems. + - Use DDS for low-latency, scalable, and fault-tolerant communication in autonomous driving systems using a publish-subscribe architecture. + - Implement distributed development techniques by splitting the simulation platform into independent, safety-isolated components. + prerequisites: - - Two Arm-based Neoverse cloud instances or a local Arm Neoverse Linux computer with at least 16 CPUs and 32GB of RAM. - - To have completed [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/). - - Basic knowledge of using Docker. + - Access to two Arm-based Neoverse cloud instances, or a local Arm Neoverse Linux system with at least 16 CPUs and 32 GB of RAM. + - Completion of the [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) Learning Path. + - Basic familiarity with Docker. author: - Odin Shen From 03489bece5d2e78fbf54e1be8769b414fb5e4ad6 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Mon, 21 Jul 2025 20:01:35 +0000 Subject: [PATCH 02/21] Refining --- .../1_functional_safety.md | 22 +++++++++++-------- .../openadkit2_safetyisolation/_index.md | 7 +++--- 2 files changed, 16 insertions(+), 13 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1_functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1_functional_safety.md index d08f796580..9c84c5a943 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1_functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1_functional_safety.md @@ -1,31 +1,35 @@ --- -title: Functional Safety for automotive software development +title: Functional safety for automotive software development weight: 2 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Why Functional Safety Matters in Automotive Software +## Why functional safety matters -Functional Safety refers to a system's ability to detect potential faults and respond appropriately to ensure that the system remains in a safe state, preventing harm to individuals or damage to equipment. +Functional safety refers to a system's ability to detect potential faults and respond appropriately to ensure that the system remains in a safe state, preventing harm to individuals or damage to equipment. This is particularly important in automotive, autonomous driving, medical devices, industrial control, robotics and aerospace applications, where system failures can lead to severe consequences. -In software development, Functional Safety focuses on minimizing risks through software design, testing, and validation to ensure that critical systems operate in a predictable, reliable, and verifiable manner. This means developers must consider: +In software development, functional safety focuses on minimizing risks through software design, testing, and validation to ensure that critical systems operate in a predictable, reliable, and verifiable manner. + +This means developers must consider: + - Error detection mechanisms - Exception handling - Redundancy design - Development processes compliant with safety standards -### Definition and Importance of Functional Safety +## Functional safety: purpose and risk management principles + The core of Functional Safety lies in risk management, which aims to reduce the impact of system failures. In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a safe state, preventing incorrect driving decisions. The three core objectives of Functional Safety are: -1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In the electric vehicle, the battery systems monitor temperature to prevent overheating. +1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In electric vehicles, battery systems monitor temperature to prevent overheating. 2. Detection: Quickly identifying errors using built-in diagnostic mechanisms, such as built-in self-test. 3. Mitigation: Controlling the impact of failures to ensure the overall safety of the system. @@ -46,7 +50,7 @@ Key Concepts of ISO 26262: Typical Application Scenarios: - Autonomous Driving Systems: - - Ensures that even if sensors (e.g., LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. + - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. - Powertrain Control: - Prevents braking system failures that could lead to loss of control. - Battery Management System (BMS): @@ -77,7 +81,7 @@ The table below compares the characteristics of a General ECU and a Safety Islan | Feature | General ECU | Safety Island | |------------------------|----------------------------|--------------------------------------| -| Purpose | Comfort / non-safety logic | Safety-critical decision making | +| Purpose | Comfort/non-safety logic | Safety-critical decision making | | OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | | Isolation | Soft partitioning | Hard isolation (hardware-enforced) | | Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | @@ -94,7 +98,7 @@ Key Capabilities of Safety Island - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. - Providing Essential Safety Functions - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: - - Autonomous Vehicles → Safe stopping (Fail-Safe Mode) + - Autonomous Vehicles → Safe stopping (fail-safe mode) - Industrial Equipment → Emergency power cutoff or speed reduction ### Why Safety Island Matters for Functional Safety diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md index 54dc4c5a23..af4122a877 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md @@ -10,10 +10,9 @@ minutes_to_complete: 60 who_is_this_for: This Learning Path targets advanced automotive software engineers developing safety-critical systems. It demonstrates how to use Arm Neoverse cloud infrastructure to accelerate ISO-26262 compliant software prototyping and testing workflows. learning_objectives: - - Apply Functional Safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems. - - Use DDS for low-latency, scalable, and fault-tolerant communication in autonomous driving systems using a publish-subscribe architecture. - - Implement distributed development techniques by splitting the simulation platform into independent, safety-isolated components. - + - Apply functional safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems. + - Use DDS and a publish-subscribe architecture for low-latency, scalable, and fault-tolerant communication in autonomous driving systems. + - Implement distributed development by separating the simulation platform into independent, safety-isolated components. prerequisites: - Access to two Arm-based Neoverse cloud instances, or a local Arm Neoverse Linux system with at least 16 CPUs and 32 GB of RAM. From 59f59c5cbb5bde1832b670458026810e9957f33e Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Tue, 22 Jul 2025 13:30:19 +0000 Subject: [PATCH 03/21] Fixed some review comments. --- .../3_container_spliting.md | 6 +- .../openadkit2_safetyisolation/_index.md | 2 +- tools/enhanced_style_check.py | 430 +++++++++++++ tools/style_rules.json | 577 ++++++++++++++++++ 4 files changed, 1011 insertions(+), 4 deletions(-) create mode 100644 tools/enhanced_style_check.py create mode 100644 tools/style_rules.json diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md index 94c5d71714..75270ef229 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md @@ -55,7 +55,7 @@ To enable ROS 2 and DDS communication between the two nodes, configure network a If you are using AWS EC2, both instances should be assigned to the same Security Group. Within the EC2 Security Group settings: -- Add an inbound rule that allows all traffic from the same Security Group by setting he source to the security group itself. +- Add an inbound rule that allows all traffic from the same Security Group by setting the source to the security group itself. - Outbound traffic is typically allowed by default and usually does not require changes. ![img2 alt-text#center](security_group.jpg "Figure 2: AWS Security Group Setting") @@ -185,7 +185,7 @@ To ensure that each container uses your custom DDS configuration, mount the curr Add this to every container definition to ensure consistent behavior across the deployment. -Here is the complete XML file: +Here is the complete YAML file: ```YAML services: @@ -317,7 +317,7 @@ export TIMEOUT=300 docker compose -f docker-compose-2ins.yml run --rm planning-control bash ``` -Once inside the container shell, activate the ROS 2 environment and start publishing to the /hello topic: +Once inside the container shell, activate the ROS 2 environment and start listening to the /hello topic: ```bash # Inside the container: diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md index af4122a877..4d5762b126 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md @@ -1,5 +1,5 @@ --- -title: Prototype safety-critical isolation for autonomous systems on Neoverse +title: Prototype safety-critical isolation for autonomous application on Neoverse draft: true cascade: diff --git a/tools/enhanced_style_check.py b/tools/enhanced_style_check.py new file mode 100644 index 0000000000..93de0209af --- /dev/null +++ b/tools/enhanced_style_check.py @@ -0,0 +1,430 @@ + +def extract_sentences_with_matches(text, pattern): + import re + sentences = re.split(r'(?<=[.!?])\s+', text) + matches = [] + for sentence in sentences: + if re.search(pattern, sentence): + matches.append(sentence.strip()) + return matches + +def apply_manual_review_rules(text, rules): + suggestions = [] + for rule in rules: + pattern = re.compile(rule["pattern"]) + matches = pattern.finditer(text) + for match in matches: + sentence = extract_sentences_with_matches(text, rule["pattern"]) + suggestions.append({ + "match": match.group(), + "replacement": rule["replacement"], + "reason": rule["reason"], + "sentence": sentence + }) + return suggestions + + +#!/usr/bin/env python3 +""" +Enhanced style checker for Arm Learning Paths content. +This script checks markdown files against writing style guidelines from a JSON file +and uses spaCy for passive voice detection. +""" + +import argparse +import json +import os +import re +import sys +from pathlib import Path + +# Import spaCy if available +try: + import spacy + SPACY_AVAILABLE = True + # Try to load the English model + try: + nlp = spacy.load("en_core_web_sm") + except: + print("Warning: spaCy model 'en_core_web_sm' not found. Will try to download it.") + try: + from spacy.cli import download + download("en_core_web_sm") + nlp = spacy.load("en_core_web_sm") + print("Successfully downloaded and loaded spaCy model.") + except: + print("Error: Could not download spaCy model. Passive voice detection will be limited.") + SPACY_AVAILABLE = False +except ImportError: + print("Warning: spaCy not installed. Using basic passive voice detection.") + SPACY_AVAILABLE = False + +def load_style_rules(rules_file): + """Load style rules from a JSON file.""" + try: + with open(rules_file, "r", encoding="utf-8") as f: + return json.load(f) + except Exception as e: + print(f"Error loading style rules: {e}") + return [] + +def is_in_code_block(lines, line_index): + """Check if the line is within a code block.""" + code_block_count = 0 + for i in range(line_index): + if re.match(r'^```', lines[i]): + code_block_count += 1 + + return code_block_count % 2 == 1 # Odd count means inside a code block + +def is_in_yaml_frontmatter(lines, line_index): + """Check if the line is within YAML frontmatter.""" + if line_index == 0 and lines[0].strip() == '---': + return True + + frontmatter_markers = 0 + for i in range(line_index): + if lines[i].strip() == '---': + frontmatter_markers += 1 + + # If we've seen an odd number of markers, we're in frontmatter + return frontmatter_markers % 2 == 1 + +def capitalize_if_at_start(original, replacement, match): + """Capitalize the replacement if it's at the start of a sentence.""" + # Check if the match is at the start of the string or after a period and space + start_of_sentence = match.start() == 0 or (match.start() > 1 and original[match.start()-2:match.start()] == '. ') + + if start_of_sentence and replacement and replacement[0].islower(): + return replacement[0].upper() + replacement[1:] + return replacement + +def detect_passive_voice_with_spacy(text): + """ + Detect passive voice using spaCy's dependency parsing. + Returns a list of (passive_text, suggested_active) tuples. + """ + if not SPACY_AVAILABLE: + return [] + + doc = nlp(text) + passive_constructions = [] + + for token in doc: + # Look for passive auxiliary verbs + if token.dep_ == "auxpass": + # Find the main verb + verb = token.head + + # Find the subject (usually nsubjpass) + subject = None + for child in verb.children: + if child.dep_ == "nsubjpass": + subject = child + break + + # Find the agent (usually introduced by "by") + agent = None + for child in verb.children: + if child.dep_ == "agent": + for agent_child in child.children: + if agent_child.dep_ == "pobj": + agent = agent_child + break + break + + # If we have both subject and agent, we can suggest an active voice alternative + if subject and agent: + # Extract the spans of text + passive_span = doc[max(0, subject.i - 1):min(len(doc), verb.i + 2)] + if agent.i > verb.i: + passive_span = doc[max(0, subject.i - 1):min(len(doc), agent.i + 1)] + + # Create active voice suggestion + active_suggestion = f"{agent.text} {verb.lemma_} {subject.text}" + + # Capitalize if at start of sentence + if passive_span.start == 0 or (passive_span.start > 1 and doc[passive_span.start-2].text == '.'): + active_suggestion = active_suggestion[0].upper() + active_suggestion[1:] + + passive_constructions.append((passive_span.text, active_suggestion)) + + return passive_constructions + +def fix_passive_voice(line): + """ + Fix passive voice constructions by swapping subject and object. + This is a more sophisticated approach than simple pattern replacement. + """ + # Common passive voice patterns with specific replacements + passive_patterns = [ + (r'The data is processed by the system', r'The system processes the data'), + (r'The code is handled by the compiler', r'The compiler handles the code'), + (r'The configuration was managed by the user', r'The user managed the configuration'), + (r'The documentation was created by the team', r'The team created the documentation'), + (r'The results are generated by the algorithm', r'The algorithm generates the results'), + (r'The API is provided by the service', r'The service provides the API') + ] + + # Try each specific pattern first + for pattern, replacement in passive_patterns: + if re.search(pattern, line, re.IGNORECASE): + return re.sub(pattern, replacement, line, flags=re.IGNORECASE) + + # Generic patterns as fallback + generic_patterns = [ + # Present tense passive + (r'(\w+) is (\w+ed) by (\w+)', r'\3 \2s \1'), + (r'(\w+) are (\w+ed) by (\w+)', r'\3 \2 \1'), + # Past tense passive + (r'(\w+) was (\w+ed) by (\w+)', r'\3 \2 \1'), + (r'(\w+) were (\w+ed) by (\w+)', r'\3 \2 \1') + ] + + for pattern, replacement in generic_patterns: + if re.search(pattern, line): + return re.sub(pattern, replacement, line) + + return line + +def check_style(content, file_path, style_rules): + """Check content against style rules and return suggestions.""" + suggestions = [] + lines = content.split("\n") + + # First, check for passive voice using spaCy if available + if SPACY_AVAILABLE: + # Process each paragraph separately to maintain context + paragraphs = [] + current_paragraph = [] + + for i, line in enumerate(lines): + # Skip code blocks, YAML frontmatter, headings, and links + if (is_in_code_block(lines, i) or + is_in_yaml_frontmatter(lines, i) or + re.match(r'^#+\s', line) or + re.search(r'^\s*\[.*\]:\s*', line)): + # End the current paragraph if any + if current_paragraph: + paragraphs.append((current_paragraph[0], " ".join(current_paragraph[1]))) + current_paragraph = [] + continue + + # Skip empty lines - they end paragraphs + if not line.strip(): + if current_paragraph: + paragraphs.append((current_paragraph[0], " ".join(current_paragraph[1]))) + current_paragraph = [] + continue + + # Add line to current paragraph + if not current_paragraph: + current_paragraph = [i, [line]] + else: + current_paragraph[1].append(line) + + # Add the last paragraph if any + if current_paragraph: + paragraphs.append((current_paragraph[0], " ".join(current_paragraph[1]))) + + # Check each paragraph for passive voice + for start_line, paragraph_text in paragraphs: + passive_constructions = detect_passive_voice_with_spacy(paragraph_text) + + for passive_text, active_suggestion in passive_constructions: + # Find which line contains this passive construction + line_offset = 0 + for j, line in enumerate(lines[start_line:start_line + 10]): # Look at next 10 lines max + if passive_text in line: + line_index = start_line + j + suggestions.append({ + "file": file_path, + "line": line_index + 1, # 1-based line numbers + "original": line, + "suggested": line.replace(passive_text, active_suggestion), + "reason": "Convert passive voice to active voice for clarity and directness (detected by spaCy)." + }) + break + + # Then check each line against style rules + for i, line in enumerate(lines): + # Skip code blocks and YAML frontmatter + if is_in_code_block(lines, i) or is_in_yaml_frontmatter(lines, i): + continue + + # Skip headings (lines starting with #) + if re.match(r'^#+\s', line): + continue + + # Skip links and image references + if re.search(r'^\s*\[.*\]:\s*', line): + continue + + # Check for passive voice using regex (as fallback) + if not SPACY_AVAILABLE: + passive_patterns = [ + r'\b(?:is|are|was|were)\s+\w+ed\s+by\b', + r'\b(?:is|are|was|were)\s+(?:handled|managed|created|generated|provided)\s+by\b' + ] + + for pattern in passive_patterns: + if re.search(pattern, line, re.IGNORECASE): + # Try to fix passive voice + fixed_line = fix_passive_voice(line) + if fixed_line != line: + suggestions.append({ + "file": file_path, + "line": i + 1, + "original": line, + "suggested": fixed_line, + "reason": "Convert passive voice to active voice for clarity and directness." + }) + # Only one suggestion per line to avoid conflicts + break + + # If we already have a suggestion for this line, skip further checks + if any(sugg["line"] == i + 1 for sugg in suggestions): + continue + + # Check against other style rules + for rule in style_rules: + matches = list(re.finditer(rule["pattern"], line, re.IGNORECASE)) + for match in matches: + # Create a suggestion + original = line + + # Get the matched text + matched_text = match.group(0) + + # Determine if replacement should be capitalized + replacement = rule["replacement"] + if match.start() == 0 or (match.start() >= 2 and line[match.start()-2:match.start()] == '. '): + if replacement and replacement[0].islower(): + replacement = replacement[0].upper() + replacement[1:] + + # Apply the replacement + suggested = line[:match.start()] + replacement + line[match.end():] + + if original != suggested: + suggestions.append({ + "file": file_path, + "line": i + 1, + "original": original, + "suggested": suggested, + "reason": rule["reason"], + }) + # Only one suggestion per line to avoid conflicts + break + + return suggestions + +def save_suggestions_to_file(suggestions, output_file="style_suggestions.json"): + """Save suggestions to a JSON file.""" + with open(output_file, "w") as f: + json.dump(suggestions, f, indent=2) + print(f"Saved suggestions to {output_file}") + +def print_suggestions(suggestions): + """Print suggestions in a readable format.""" + if not suggestions: + print("No style issues found.") + return + + print(f"\nFound {len(suggestions)} style issues:") + print("=" * 80) + + for i, sugg in enumerate(suggestions, 1): + print(f"Issue {i}:") + print(f"File: {sugg['file']}") + print(f"Line: {sugg['line']}") + print(f"Reason: {sugg['reason']}") + print(f"Original: {sugg['original']}") + print(f"Suggested: {sugg['suggested']}") + print("-" * 80) + +def main(): + parser = argparse.ArgumentParser(description="Check markdown files for style issues") + parser.add_argument("--file", help="Path to a specific markdown file to check") + parser.add_argument("--dir", help="Directory containing markdown files to check") + parser.add_argument("--rules", default="tools/style_rules.json", help="JSON file containing style rules") + parser.add_argument("--output", default="style_suggestions.json", help="Output file for suggestions") + parser.add_argument("--install-spacy", action="store_true", help="Install spaCy and download the English model") + args = parser.parse_args() + + # Install spaCy if requested + if args.install_spacy: + print("Installing spaCy and downloading the English model...") + import subprocess + subprocess.call([sys.executable, "-m", "pip", "install", "spacy"]) + subprocess.call([sys.executable, "-m", "spacy", "download", "en_core_web_sm"]) + print("Installation complete. Please run the script again without --install-spacy.") + sys.exit(0) + + if not args.file and not args.dir: + print("Error: Please provide either --file or --dir argument") + sys.exit(1) + + # Load style rules + style_rules = load_style_rules(args.rules) + if not style_rules: + print("Error: No style rules loaded. Check the rules file.") + sys.exit(1) + + print(f"Loaded {len(style_rules)} style rules from {args.rules}") + + all_suggestions = [] + + # Check a specific file + if args.file: + if not os.path.isfile(args.file): + print(f"Error: File not found: {args.file}") + sys.exit(1) + + if not args.file.endswith((".md", ".mdx")): + print(f"Warning: {args.file} is not a markdown file. Checking anyway.") + + with open(args.file, "r", encoding="utf-8") as f: + content = f.read() + + suggestions = check_style(content, args.file, style_rules) + all_suggestions.extend(suggestions) + print(f"Checked {args.file}: Found {len(suggestions)} style issues") + + # Check all markdown files in a directory + if args.dir: + if not os.path.isdir(args.dir): + print(f"Error: Directory not found: {args.dir}") + sys.exit(1) + + for root, _, files in os.walk(args.dir): + for file in files: + if file.endswith((".md", ".mdx")): + file_path = os.path.join(root, file) + with open(file_path, "r", encoding="utf-8") as f: + content = f.read() + + suggestions = check_style(content, file_path, style_rules) + all_suggestions.extend(suggestions) + print(f"Checked {file_path}: Found {len(suggestions)} style issues") + + # Print and save suggestions + print_suggestions(all_suggestions) + save_suggestions_to_file(all_suggestions, args.output) + +if __name__ == "__main__": + main() + + + +def run_manual_review_interactively(text, rules): + updated_text = text + manual_suggestions = apply_manual_review_rules(text, rules) + for suggestion in manual_suggestions: + for sentence in suggestion["sentence"]: + print(f"\nContext: {sentence}") + print(f"Suggestion: Replace '{suggestion['match']}' with '{suggestion['replacement']}'") + print(f"Reason: {suggestion['reason']}") + choice = input("Apply this change? (y/n): ").strip().lower() + if choice == 'y': + updated_text = updated_text.replace(suggestion["match"], suggestion["replacement"], 1) + return updated_text diff --git a/tools/style_rules.json b/tools/style_rules.json new file mode 100644 index 0000000000..c4967a956c --- /dev/null +++ b/tools/style_rules.json @@ -0,0 +1,577 @@ +[ + { + "pattern": "\\butilize\\b", + "replacement": "use", + "reason": "Use 'use' instead of 'utilize' for simplicity." + }, + { + "pattern": "\\butilizes\\b", + "replacement": "uses", + "reason": "Use 'uses' instead of 'utilizes' for simplicity." + }, + { + "pattern": "\\butilized\\b", + "replacement": "used", + "reason": "Use 'used' instead of 'utilized' for simplicity." + }, + { + "pattern": "\\butilizing\\b", + "replacement": "using", + "reason": "Use 'using' instead of 'utilizing' for simplicity." + }, + { + "pattern": "\\butilization\\b", + "replacement": "use", + "reason": "Use 'use' instead of 'utilization' for simplicity." + }, + { + "pattern": "\\boptimize\\b", + "replacement": "improve", + "reason": "Simplify language by replacing 'optimize' with 'improve'." + }, + { + "pattern": "\\boptimizes\\b", + "replacement": "improves", + "reason": "Simplify language by replacing 'optimizes' with 'improves'." + }, + { + "pattern": "\\boptimized\\b", + "replacement": "improved", + "reason": "Simplify language by replacing 'optimized' with 'improved'." + }, + { + "pattern": "\\boptimizing\\b", + "replacement": "improving", + "reason": "Simplify language by replacing 'optimizing' with 'improving'." + }, + { + "pattern": "\\boptimization\\b", + "replacement": "improvement", + "reason": "Simplify language by replacing 'optimization' with 'improvement'." + }, + { + "pattern": "\\boptimizations\\b", + "replacement": "improvements", + "reason": "Simplify language by replacing 'optimizations' with 'improvements'." + }, + { + "pattern": "\\bin order to\\b", + "replacement": "to", + "reason": "Use 'to' instead of 'in order to' for conciseness." + }, + { + "pattern": "\\bplease note that\\b", + "replacement": "", + "reason": "Remove 'please note that' for directness." + }, + { + "pattern": "\\byou should\\b", + "replacement": "", + "reason": "Be direct with instructions, avoid 'you should'." + }, + { + "pattern": "\\bis able to\\b", + "replacement": "can", + "reason": "Use 'can' instead of 'is able to' for simplicity." + }, + { + "pattern": "\\bare able to\\b", + "replacement": "can", + "reason": "Use 'can' instead of 'are able to' for simplicity." + }, + { + "pattern": "\\bwas able to\\b", + "replacement": "could", + "reason": "Use 'could' instead of 'was able to' for simplicity." + }, + { + "pattern": "\\bwere able to\\b", + "replacement": "could", + "reason": "Use 'could' instead of 'were able to' for simplicity." + }, + { + "pattern": "\\bdue to the fact that\\b", + "replacement": "because", + "reason": "Use 'because' instead of 'due to the fact that' for conciseness." + }, + { + "pattern": "\\bat this point in time\\b", + "replacement": "now", + "reason": "Use 'now' instead of 'at this point in time' for conciseness." + }, + { + "pattern": "\\bfor the purpose of\\b", + "replacement": "for", + "reason": "Use 'for' instead of 'for the purpose of' for conciseness." + }, + { + "pattern": "\\bprior to\\b", + "replacement": "before", + "reason": "Use 'before' instead of 'prior to' for simplicity." + }, + { + "pattern": "\\bsubsequent to\\b", + "replacement": "after", + "reason": "Use 'after' instead of 'subsequent to' for simplicity." + }, + { + "pattern": "\\ba large number of\\b", + "replacement": "many", + "reason": "Use 'many' instead of 'a large number of' for conciseness." + }, + { + "pattern": "\\ba majority of\\b", + "replacement": "most", + "reason": "Use 'most' instead of 'a majority of' for conciseness." + }, + { + "pattern": "\\bin spite of\\b", + "replacement": "despite", + "reason": "Use 'despite' instead of 'in spite of' for conciseness." + }, + { + "pattern": "\\bwith regard to\\b", + "replacement": "about", + "reason": "Use 'about' instead of 'with regard to' for conciseness." + }, + { + "pattern": "\\bwith respect to\\b", + "replacement": "about", + "reason": "Use 'about' instead of 'with respect to' for conciseness." + }, + { + "pattern": "\\bwe recommend\\b", + "replacement": "it is recommended", + "reason": "Use 'it is recommended' instead of 'we recommend' for a more neutral tone." + }, + { + "pattern": "\\bwe suggest\\b", + "replacement": "it is suggested", + "reason": "Use 'it is suggested' instead of 'we suggest' for a more neutral tone." + }, + { + "pattern": "\\bwe advise\\b", + "replacement": "it is advised", + "reason": "Use 'it is advised' instead of 'we advise' for a more neutral tone." + }, + { + "pattern": "\\bwe will\\b", + "replacement": "you will", + "reason": "Use 'you will' instead of 'we will' to address the reader directly." + }, + { + "pattern": "\\bwe can\\b", + "replacement": "you can", + "reason": "Use 'you can' instead of 'we can' to address the reader directly." + }, + { + "pattern": "\\bwe have\\b", + "replacement": "you have", + "reason": "Use 'you have' instead of 'we have' to address the reader directly." + }, + { + "pattern": "\\bwe are\\b", + "replacement": "you are", + "reason": "Use 'you are' instead of 'we are' to address the reader directly." + }, + { + "pattern": "\\bwe need to\\b", + "replacement": "you need to", + "reason": "Use 'you need to' instead of 'we need to' to address the reader directly." + }, + { + "pattern": "\\bwe must\\b", + "replacement": "you must", + "reason": "Use 'you must' instead of 'we must' to address the reader directly." + }, + { + "pattern": "\\bwe should\\b", + "replacement": "you should", + "reason": "Use 'you should' instead of 'we should' to address the reader directly." + }, + { + "pattern": "\\bis processed by\\b", + "replacement": "processes", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bare processed by\\b", + "replacement": "process", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwas processed by\\b", + "replacement": "processed", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwere processed by\\b", + "replacement": "processed", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bis handled by\\b", + "replacement": "handles", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bare handled by\\b", + "replacement": "handle", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwas handled by\\b", + "replacement": "handled", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwere handled by\\b", + "replacement": "handled", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bis managed by\\b", + "replacement": "manages", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bare managed by\\b", + "replacement": "manage", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwas managed by\\b", + "replacement": "managed", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwere managed by\\b", + "replacement": "managed", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bis created by\\b", + "replacement": "creates", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bare created by\\b", + "replacement": "create", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwas created by\\b", + "replacement": "created", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwere created by\\b", + "replacement": "created", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bis generated by\\b", + "replacement": "generates", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bare generated by\\b", + "replacement": "generate", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwas generated by\\b", + "replacement": "generated", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwere generated by\\b", + "replacement": "generated", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bis provided by\\b", + "replacement": "provides", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bare provided by\\b", + "replacement": "provide", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwas provided by\\b", + "replacement": "provided", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bwere provided by\\b", + "replacement": "provided", + "reason": "Use active voice instead of passive voice." + }, + { + "pattern": "\\bARM\\b", + "replacement": "Arm", + "reason": "Use 'Arm' instead of 'ARM' for clarity or consistency." + }, + { + "pattern": "\\bARM's\\b", + "replacement": "Arm's", + "reason": "Use 'Arm's' instead of 'ARM's' for clarity or consistency." + }, + { + "pattern": "\\badaptor\\b", + "replacement": "adapter", + "reason": "Use 'adapter' instead of 'adaptor' for clarity or consistency." + }, + { + "pattern": "\\banalyse\\b", + "replacement": "analyze", + "reason": "Use 'analyze' instead of 'analyse' for clarity or consistency." + }, + { + "pattern": "\\bback\\-end\\b", + "replacement": "backend", + "reason": "Use 'backend' instead of 'back-end' for clarity or consistency." + }, + { + "pattern": "\\bcustom\\-made\\b", + "replacement": "custom-built", + "reason": "Use 'custom-built' instead of 'custom-made' for clarity or consistency." + }, + { + "pattern": "\\bdouble\\-click\\b", + "replacement": "double-tap", + "reason": "Use 'double-tap' instead of 'double-click' for clarity or consistency." + }, + { + "pattern": "\\beasy\\ to\\ use\\b", + "replacement": "easy-to-use", + "reason": "Use 'easy-to-use' instead of 'easy to use' for clarity or consistency." + }, + { + "pattern": "\\beliminate\\b", + "replacement": "remove", + "reason": "Use 'remove' instead of 'eliminate' for clarity or consistency." + }, + { + "pattern": "\\bextract\\b", + "replacement": "remove", + "reason": "Use 'remove' instead of 'extract' for clarity or consistency." + }, + { + "pattern": "\\btake\\ away\\b", + "replacement": "remove", + "reason": "Use 'remove' instead of 'take away' for clarity or consistency." + }, + { + "pattern": "\\be\\.g\\.\\b", + "replacement": "for example", + "reason": "Use 'for example' instead of 'e.g.' for clarity or consistency." + }, + { + "pattern": "\\bi\\.e\\.\\b", + "replacement": "that is", + "reason": "Use 'that is' instead of 'i.e.' for clarity or consistency." + }, + { + "pattern": "\\bergo\\b", + "replacement": "therefore", + "reason": "Use 'therefore' instead of 'ergo' for clarity or consistency." + }, + { + "pattern": "\\bdo\\ not\\b", + "replacement": "don't", + "reason": "Use 'don't' instead of 'do not' for clarity or consistency." + }, + { + "pattern": "\\bit\\ is\\b", + "replacement": "it's", + "reason": "Use 'it's' instead of 'it is' for clarity or consistency." + }, + { + "pattern": "\\bis\\ not\\b", + "replacement": "isn't", + "reason": "Use 'isn't' instead of 'is not' for clarity or consistency." + }, + { + "pattern": "\\bthat\\ is\\b", + "replacement": "that's", + "reason": "Use 'that's' instead of 'that is' for clarity or consistency." + }, + { + "pattern": "\\bviz\\.\\b", + "replacement": "namely", + "reason": "Use 'namely' instead of 'viz.' for clarity or consistency." + }, + { + "pattern": "\\btry\\ not\\ to\\b", + "replacement": "avoid", + "reason": "Use 'avoid' instead of 'try not to' for clarity or consistency." + }, + { + "pattern": "\\brefer\\ to\\b", + "replacement": "see", + "reason": "Use 'see' instead of 'refer to' for clarity or consistency." + }, + { + "pattern": "\\bsub\\-optimal\\b", + "replacement": "suboptimal", + "reason": "Use 'suboptimal' instead of 'sub-optimal' for clarity or consistency." + }, + { + "pattern": "\\bserver\\-less\\b", + "replacement": "serverless", + "reason": "Use 'serverless' instead of 'server-less' for clarity or consistency." + }, + { + "pattern": "\\btouch\\ screen\\b", + "replacement": "touchscreen", + "reason": "Use 'touchscreen' instead of 'touch screen' for clarity or consistency." + }, + { + "pattern": "\\bctrl\\ key\\b", + "replacement": "Ctrl key", + "reason": "Use 'Ctrl key' instead of 'ctrl key' for clarity or consistency." + }, + { + "pattern": "\\bspot\\b", + "replacement": "identify", + "reason": "Use 'identify' instead of 'spot' for clarity or consistency." + }, + { + "pattern": "\\bleverage\\b", + "replacement": "take advantage of", + "reason": "Use 'take advantage of' instead of 'leverage' for clarity or consistency." + }, + { + "pattern": "\\blicence\\b", + "replacement": "license", + "reason": "Use 'license' instead of 'licence' for clarity or consistency." + }, + { + "pattern": "\\bmassive\\b", + "replacement": "significant", + "reason": "Use 'significant' instead of 'massive' for clarity or consistency." + }, + { + "pattern": "\\brespond\\ to\\ the\\ ask\\b", + "replacement": "respond to the request", + "reason": "Use 'respond to the request' instead of 'respond to the ask' for clarity or consistency." + }, + { + "pattern": "\\brevert\\ back\\ to\\b", + "replacement": "revert to", + "reason": "Use 'revert to' instead of 'revert back to' for clarity or consistency." + }, + { + "pattern": "\\bpower\\ off\\b", + "replacement": "turn off", + "reason": "Use 'turn off' instead of 'power off' for clarity or consistency." + }, + { + "pattern": "\\bpower\\ on\\b", + "replacement": "turn on", + "reason": "Use 'turn on' instead of 'power on' for clarity or consistency." + }, + { + "pattern": "\\bpress\\b", + "replacement": "select", + "reason": "Use 'select' instead of 'press' for clarity or consistency." + }, + { + "pattern": "\\bsmart\\ technology\\b", + "replacement": "intelligent technology", + "reason": "Use 'intelligent technology' instead of 'smart technology' for clarity or consistency." + }, + { + "pattern": "\\blearning\\ path\\b", + "replacement": "Learning Path", + "reason": "Use 'Learning Path' instead of 'learning path' for clarity or consistency." + }, + { + "pattern": "\\bwearable\\b", + "replacement": "wearable device", + "reason": "Use 'wearable device' instead of 'wearable' for clarity or consistency." + }, + { + "pattern": "\\bGB\\ per\\ second\\b", + "replacement": "Gbps", + "reason": "Use 'Gbps' instead of 'GB per second' for clarity or consistency." + }, + { + "pattern": "\\bkey\\ combination\\b", + "replacement": "keyboard shortcut", + "reason": "Use 'keyboard shortcut' instead of 'key combination' for clarity or consistency." + }, + { + "pattern": "\\blearn\\ how\\ to\\ use\\b", + "replacement": "use", + "reason": "Use 'use' instead of 'learn how to use' for clarity or consistency." + }, + { + "pattern": "\\brequire\\b", + "replacement": "need", + "reason": "Use 'need' instead of 'require' for clarity or consistency." + }, + { + "pattern": "\\bFollow\\ the\\ steps\\ below\\ to\\b", + "replacement": "To", + "reason": "Use 'To' instead of 'Follow the steps below to' for clarity or consistency." + }, + { + "pattern": "\\bwe\\ observe\\b", + "replacement": "you can see", + "reason": "Use 'you can see' instead of 'we observe' for clarity or consistency." + }, + { + "pattern": "\\bmay\\b", + "replacement": "can", + "reason": "Use 'can' instead of 'may' for clarity or consistency." + }, + { + "pattern": "\\bwould\\b", + "replacement": "does", + "reason": "Use 'does' instead of 'would' for clarity or consistency." + }, + { + "pattern": "\\bwe\\b", + "replacement": "you", + "reason": "Use 'you' instead of 'we' for clarity or consistency." + }, + { + "pattern": "\\byou\\ are\\b", + "replacement": "you're", + "reason": "Use 'you're' instead of 'you are' for clarity or consistency." + }, + { + "pattern": "\\byou\\ will\\b", + "replacement": "you'll", + "reason": "Use 'you'll' instead of 'you will' for clarity or consistency." + }, + { + "pattern": "\\bCloud\\ Native\\b", + "replacement": "cloud native", + "reason": "Use 'cloud native' instead of 'Cloud Native' for clarity or consistency." + }, + { + "pattern": "\\bseeking\\ to\\b", + "replacement": "looking to", + "reason": "Use 'looking to' instead of 'seeking to' for clarity or consistency." + }, + { + "pattern": "\\bsince\\b", + "replacement": "because", + "reason": "Use 'because' instead of 'since' for clarity or consistency." + }, + { + "pattern": "\\bin\\ addition\\b", + "replacement": "also", + "reason": "Use 'also' instead of 'in addition' for clarity or consistency." + }, + { + "pattern": "\\bimpact\\ performance\\b", + "replacement": "affect performance", + "reason": "Use 'affect performance' instead of 'impact performance' for clarity or consistency." + } +] \ No newline at end of file From e82ca28c2a294eb16d670a5421ca2a62e5851e68 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Tue, 22 Jul 2025 20:07:49 +0000 Subject: [PATCH 04/21] Split functional safety content into modular Learn steps - Created 5-step structure for "Functional safety for automotive software development" - Reorganized content to follow Microsoft Learn format - Aligned section titles with sentence case and clear instructional goals - Added consistent context-before-concept framing and bullet parallelism - Preserved technical depth while improving readability and flow --- ...onal_safety.md => 1a_functional_safety.md} | 0 .../openadkit2_safetyisolation/1b_purpose.md | 123 ++++++++++++++++++ .../openadkit2_safetyisolation/1c_ISO26262 | 109 ++++++++++++++++ .../1d_safety_island_arch.md | 104 +++++++++++++++ .../1e_implement functional_safety.md | 30 +++++ .../2_data_distribution_service.md | 2 +- .../3_container_spliting.md | 2 +- .../4_multiinstance_executing.md | 2 +- .../openadkit2_safetyisolation/_index.md | 17 +-- 9 files changed, 378 insertions(+), 11 deletions(-) rename content/learning-paths/automotive/openadkit2_safetyisolation/{1_functional_safety.md => 1a_functional_safety.md} (100%) create mode 100644 content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md create mode 100644 content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 create mode 100644 content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md create mode 100644 content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1_functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md similarity index 100% rename from content/learning-paths/automotive/openadkit2_safetyisolation/1_functional_safety.md rename to content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md new file mode 100644 index 0000000000..c1aa4264d2 --- /dev/null +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md @@ -0,0 +1,123 @@ +--- +title: Purpose and risk management principles +weight: 3 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Functional safety: purpose and risk management principles + + +The core of Functional Safety lies in risk management, which aims to reduce the impact of system failures. + +In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a safe state, preventing incorrect driving decisions. + +The three core objectives of Functional Safety are: +1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In electric vehicles, battery systems monitor temperature to prevent overheating. +2. Detection: Quickly identifying errors using built-in diagnostic mechanisms, such as built-in self-test. +3. Mitigation: Controlling the impact of failures to ensure the overall safety of the system. + +This approach is critical in applications such as autonomous driving, flight control, and medical implants, where failures can result in severe consequences. + +### ISO 26262: Automotive Functional Safety Standard + +ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. + +Key Concepts of ISO 26262: +- ASIL (Automotive Safety Integrity Level) + - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). + - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). +- HARA (Hazard Analysis and Risk Assessment) + - Analyzes hazards and assesses risks to determine necessary safety measures. +- Safety Mechanisms + - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. + +Typical Application Scenarios: +- Autonomous Driving Systems: + - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. +- Powertrain Control: + - Prevents braking system failures that could lead to loss of control. +- Battery Management System (BMS): + - Prevents battery overheating or excessive discharge in electric vehicles. + +### Common Use Cases of Functional Safety in Automotive + +- Autonomous Driving: + - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. + - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. + +- Powertrain Control: + - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. + - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. + +- Battery Management Systems (BMS): + - Protects EV batteries from overheating, overcharging, or deep discharge. + - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. + +These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. +A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. + +### Safety Island: Enabling Functional Safety in Autonomous Systems + +In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. + +The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. + +| Feature | General ECU | Safety Island | +|------------------------|----------------------------|--------------------------------------| +| Purpose | Comfort/non-safety logic | Safety-critical decision making | +| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | +| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | +| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | +| Fault Handling | Best-effort recovery | Deterministic safe-state response | + +This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. + +Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. + +Key Capabilities of Safety Island +- System Health Monitoring + - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. +- Fault Detection and Isolation + - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. +- Providing Essential Safety Functions + - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: + - Autonomous Vehicles → Safe stopping (fail-safe mode) + - Industrial Equipment → Emergency power cutoff or speed reduction + +### Why Safety Island Matters for Functional Safety + +Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. + +How Safety Island Enhances Functional Safety +1. Acts as an Independent Redundant Safety Layer + - Even if the main system fails, it can still operate independently. +2. Supports ASIL-D Safety Level + - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. +3. Provides Independent Fault Detection and Recovery Mechanisms + - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. + - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. + +### Functional Safety in the Software Development Lifecycle + +Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. +For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. + +### Functional Safety Requirements in Software Development + +These practices ensure the software development process meets industry safety standards and can withstand system-level failures: +- Requirement Specification + - Clearly defining safety-critical requirements and conducting risk assessments. +- Safety-Oriented Programming + - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. +- Fault Handling Mechanisms + - Implementing redundancy design and health monitoring to handle anomalies. +- Testing and Verification + - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. +- Version Management and Change Control + - Using Git, JIRA, Polarion to track changes for safety audits. + +By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. + +This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 new file mode 100644 index 0000000000..11d99083e7 --- /dev/null +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 @@ -0,0 +1,109 @@ +--- +title: Explore ISO 26262 and ASIL levels +weight: 4 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## ISO 26262: Automotive Functional Safety Standard + +ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. + +Key Concepts of ISO 26262: +- ASIL (Automotive Safety Integrity Level) + - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). + - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). +- HARA (Hazard Analysis and Risk Assessment) + - Analyzes hazards and assesses risks to determine necessary safety measures. +- Safety Mechanisms + - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. + +Typical Application Scenarios: +- Autonomous Driving Systems: + - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. +- Powertrain Control: + - Prevents braking system failures that could lead to loss of control. +- Battery Management System (BMS): + - Prevents battery overheating or excessive discharge in electric vehicles. + +### Common Use Cases of Functional Safety in Automotive + +- Autonomous Driving: + - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. + - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. + +- Powertrain Control: + - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. + - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. + +- Battery Management Systems (BMS): + - Protects EV batteries from overheating, overcharging, or deep discharge. + - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. + +These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. +A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. + +### Safety Island: Enabling Functional Safety in Autonomous Systems + +In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. + +The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. + +| Feature | General ECU | Safety Island | +|------------------------|----------------------------|--------------------------------------| +| Purpose | Comfort/non-safety logic | Safety-critical decision making | +| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | +| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | +| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | +| Fault Handling | Best-effort recovery | Deterministic safe-state response | + +This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. + +Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. + +Key Capabilities of Safety Island +- System Health Monitoring + - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. +- Fault Detection and Isolation + - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. +- Providing Essential Safety Functions + - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: + - Autonomous Vehicles → Safe stopping (fail-safe mode) + - Industrial Equipment → Emergency power cutoff or speed reduction + +### Why Safety Island Matters for Functional Safety + +Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. + +How Safety Island Enhances Functional Safety +1. Acts as an Independent Redundant Safety Layer + - Even if the main system fails, it can still operate independently. +2. Supports ASIL-D Safety Level + - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. +3. Provides Independent Fault Detection and Recovery Mechanisms + - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. + - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. + +### Functional Safety in the Software Development Lifecycle + +Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. +For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. + +### Functional Safety Requirements in Software Development + +These practices ensure the software development process meets industry safety standards and can withstand system-level failures: +- Requirement Specification + - Clearly defining safety-critical requirements and conducting risk assessments. +- Safety-Oriented Programming + - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. +- Fault Handling Mechanisms + - Implementing redundancy design and health monitoring to handle anomalies. +- Testing and Verification + - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. +- Version Management and Change Control + - Using Git, JIRA, Polarion to track changes for safety audits. + +By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. + +This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md new file mode 100644 index 0000000000..c32097ed7b --- /dev/null +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -0,0 +1,104 @@ +--- +title: Apply functional safety with Safety Island architecture +weight: 5 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + + + + +## Functional safety: purpose and risk management principles + + +The core of Functional Safety lies in risk management, which aims to reduce the impact of system failures. + +In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a safe state, preventing incorrect driving decisions. + +The three core objectives of Functional Safety are: +1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In electric vehicles, battery systems monitor temperature to prevent overheating. +2. Detection: Quickly identifying errors using built-in diagnostic mechanisms, such as built-in self-test. +3. Mitigation: Controlling the impact of failures to ensure the overall safety of the system. + +This approach is critical in applications such as autonomous driving, flight control, and medical implants, where failures can result in severe consequences. + +### ISO 26262: Automotive Functional Safety Standard + +ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. + +Key Concepts of ISO 26262: +- ASIL (Automotive Safety Integrity Level) + - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). + - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). +- HARA (Hazard Analysis and Risk Assessment) + - Analyzes hazards and assesses risks to determine necessary safety measures. +- Safety Mechanisms + - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. + +Typical Application Scenarios: +- Autonomous Driving Systems: + - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. +- Powertrain Control: + - Prevents braking system failures that could lead to loss of control. +- Battery Management System (BMS): + - Prevents battery overheating or excessive discharge in electric vehicles. + +### Common Use Cases of Functional Safety in Automotive + +- Autonomous Driving: + - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. + - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. + +- Powertrain Control: + - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. + - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. + +- Battery Management Systems (BMS): + - Protects EV batteries from overheating, overcharging, or deep discharge. + - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. + +These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. +A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. + +### Safety Island: Enabling Functional Safety in Autonomous Systems + +In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. + +The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. + +| Feature | General ECU | Safety Island | +|------------------------|----------------------------|--------------------------------------| +| Purpose | Comfort/non-safety logic | Safety-critical decision making | +| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | +| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | +| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | +| Fault Handling | Best-effort recovery | Deterministic safe-state response | + +This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. + +Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. + +Key Capabilities of Safety Island +- System Health Monitoring + - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. +- Fault Detection and Isolation + - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. +- Providing Essential Safety Functions + - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: + - Autonomous Vehicles → Safe stopping (fail-safe mode) + - Industrial Equipment → Emergency power cutoff or speed reduction + +### Why Safety Island Matters for Functional Safety + +Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. + +How Safety Island Enhances Functional Safety +1. Acts as an Independent Redundant Safety Layer + - Even if the main system fails, it can still operate independently. +2. Supports ASIL-D Safety Level + - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. +3. Provides Independent Fault Detection and Recovery Mechanisms + - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. + - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. + diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md new file mode 100644 index 0000000000..92fbcabb10 --- /dev/null +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md @@ -0,0 +1,30 @@ +--- +title: Functional safety for automotive software development +weight: 6 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- + +## Functional Safety in the Software Development Lifecycle + +Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. +For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. + +### Functional Safety Requirements in Software Development + +These practices ensure the software development process meets industry safety standards and can withstand system-level failures: +- Requirement Specification + - Clearly defining safety-critical requirements and conducting risk assessments. +- Safety-Oriented Programming + - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. +- Fault Handling Mechanisms + - Implementing redundancy design and health monitoring to handle anomalies. +- Testing and Verification + - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. +- Version Management and Change Control + - Using Git, JIRA, Polarion to track changes for safety audits. + +By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. + +This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md index 19a36ba606..4865aa88f0 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md @@ -1,6 +1,6 @@ --- title: How to Use Data Distribution Service (DDS) -weight: 3 +weight: 7 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md index 84cc3191ff..b65a553c4f 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md @@ -1,6 +1,6 @@ --- title: Split into multiple cloud container instances -weight: 4 +weight: 8 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index def332f4e9..3357c153c1 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -1,7 +1,7 @@ --- title: Executing OpenAD Kit in a Distributed ROS 2 Instances -weight: 5 +weight: 9 ### FIXED, DO NOT MODIFY layout: learningpathall diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md index 4d5762b126..495d420c98 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md @@ -1,5 +1,5 @@ --- -title: Prototype safety-critical isolation for autonomous application on Neoverse +title: Prototype safety-critical isolation for autonomous driving systems on Neoverse draft: true cascade: @@ -7,17 +7,17 @@ cascade: minutes_to_complete: 60 -who_is_this_for: This Learning Path targets advanced automotive software engineers developing safety-critical systems. It demonstrates how to use Arm Neoverse cloud infrastructure to accelerate ISO-26262 compliant software prototyping and testing workflows. +who_is_this_for: This Learning Path is for experienced automotive engineers developing safety-critical systems. You'll learn how to accelerate ISO 26262-compliant development workflows using Arm-based cloud compute, containerized simulation, and DDS-based communication. learning_objectives: - - Apply functional safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems. - - Use DDS and a publish-subscribe architecture for low-latency, scalable, and fault-tolerant communication in autonomous driving systems. - - Implement distributed development by separating the simulation platform into independent, safety-isolated components. + - Apply functional safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems + - Use DDS and a publish-subscribe architecture for low-latency, scalable, and fault-tolerant communication in autonomous driving systems + - Implement distributed development by separating the simulation platform into independent, safety-isolated components prerequisites: - - Access to two Arm-based Neoverse cloud instances, or a local Arm Neoverse Linux system with at least 16 CPUs and 32 GB of RAM. - - Completion of the [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) Learning Path. - - Basic familiarity with Docker. + - Access to two Arm-based Neoverse cloud instances, or a local Arm Neoverse Linux system with at least 16 CPUs and 32 GB of RAM + - Completion of the [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) Learning Path + - Basic familiarity with Docker author: - Odin Shen @@ -32,6 +32,7 @@ tools_software_languages: - Python - Docker - ROS2 + - DDS operatingsystems: - Linux From 60a347d2128d92a66c049b41b2d5e0f73a2e9a4f Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Wed, 23 Jul 2025 09:09:37 +0000 Subject: [PATCH 05/21] Updates --- .../1a_functional_safety.md | 115 +----------------- .../openadkit2_safetyisolation/1b_purpose.md | 101 --------------- .../1d_safety_island_arch.md | 3 - .../openadkit2_safetyisolation/_index.md | 4 - 4 files changed, 1 insertion(+), 222 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md index 9c84c5a943..60b2e2eb60 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md @@ -21,118 +21,5 @@ This means developers must consider: - Redundancy design - Development processes compliant with safety standards -## Functional safety: purpose and risk management principles +In the following sections, you'll explore how to apply these principles throughout the software lifecycle, which ranges from risk assessment and architectural design to runtime isolation and compliance with ISO 26262. - -The core of Functional Safety lies in risk management, which aims to reduce the impact of system failures. - -In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a safe state, preventing incorrect driving decisions. - -The three core objectives of Functional Safety are: -1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In electric vehicles, battery systems monitor temperature to prevent overheating. -2. Detection: Quickly identifying errors using built-in diagnostic mechanisms, such as built-in self-test. -3. Mitigation: Controlling the impact of failures to ensure the overall safety of the system. - -This approach is critical in applications such as autonomous driving, flight control, and medical implants, where failures can result in severe consequences. - -### ISO 26262: Automotive Functional Safety Standard - -ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. - -Key Concepts of ISO 26262: -- ASIL (Automotive Safety Integrity Level) - - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). - - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). -- HARA (Hazard Analysis and Risk Assessment) - - Analyzes hazards and assesses risks to determine necessary safety measures. -- Safety Mechanisms - - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. - -Typical Application Scenarios: -- Autonomous Driving Systems: - - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. -- Powertrain Control: - - Prevents braking system failures that could lead to loss of control. -- Battery Management System (BMS): - - Prevents battery overheating or excessive discharge in electric vehicles. - -### Common Use Cases of Functional Safety in Automotive - -- Autonomous Driving: - - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. - - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. - -- Powertrain Control: - - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. - - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. - -- Battery Management Systems (BMS): - - Protects EV batteries from overheating, overcharging, or deep discharge. - - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. - -These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. -A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. - -### Safety Island: Enabling Functional Safety in Autonomous Systems - -In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. - -The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. - -| Feature | General ECU | Safety Island | -|------------------------|----------------------------|--------------------------------------| -| Purpose | Comfort/non-safety logic | Safety-critical decision making | -| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | -| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | -| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | -| Fault Handling | Best-effort recovery | Deterministic safe-state response | - -This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. - -Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. - -Key Capabilities of Safety Island -- System Health Monitoring - - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. -- Fault Detection and Isolation - - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. -- Providing Essential Safety Functions - - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: - - Autonomous Vehicles → Safe stopping (fail-safe mode) - - Industrial Equipment → Emergency power cutoff or speed reduction - -### Why Safety Island Matters for Functional Safety - -Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. - -How Safety Island Enhances Functional Safety -1. Acts as an Independent Redundant Safety Layer - - Even if the main system fails, it can still operate independently. -2. Supports ASIL-D Safety Level - - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. -3. Provides Independent Fault Detection and Recovery Mechanisms - - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. - - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. - -### Functional Safety in the Software Development Lifecycle - -Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. -For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. - -### Functional Safety Requirements in Software Development - -These practices ensure the software development process meets industry safety standards and can withstand system-level failures: -- Requirement Specification - - Clearly defining safety-critical requirements and conducting risk assessments. -- Safety-Oriented Programming - - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. -- Fault Handling Mechanisms - - Implementing redundancy design and health monitoring to handle anomalies. -- Testing and Verification - - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. -- Version Management and Change Control - - Using Git, JIRA, Polarion to track changes for safety audits. - -By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. - -This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md index c1aa4264d2..d47820b3e3 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md @@ -20,104 +20,3 @@ The three core objectives of Functional Safety are: This approach is critical in applications such as autonomous driving, flight control, and medical implants, where failures can result in severe consequences. -### ISO 26262: Automotive Functional Safety Standard - -ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. - -Key Concepts of ISO 26262: -- ASIL (Automotive Safety Integrity Level) - - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). - - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). -- HARA (Hazard Analysis and Risk Assessment) - - Analyzes hazards and assesses risks to determine necessary safety measures. -- Safety Mechanisms - - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. - -Typical Application Scenarios: -- Autonomous Driving Systems: - - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. -- Powertrain Control: - - Prevents braking system failures that could lead to loss of control. -- Battery Management System (BMS): - - Prevents battery overheating or excessive discharge in electric vehicles. - -### Common Use Cases of Functional Safety in Automotive - -- Autonomous Driving: - - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. - - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. - -- Powertrain Control: - - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. - - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. - -- Battery Management Systems (BMS): - - Protects EV batteries from overheating, overcharging, or deep discharge. - - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. - -These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. -A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. - -### Safety Island: Enabling Functional Safety in Autonomous Systems - -In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. - -The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. - -| Feature | General ECU | Safety Island | -|------------------------|----------------------------|--------------------------------------| -| Purpose | Comfort/non-safety logic | Safety-critical decision making | -| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | -| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | -| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | -| Fault Handling | Best-effort recovery | Deterministic safe-state response | - -This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. - -Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. - -Key Capabilities of Safety Island -- System Health Monitoring - - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. -- Fault Detection and Isolation - - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. -- Providing Essential Safety Functions - - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: - - Autonomous Vehicles → Safe stopping (fail-safe mode) - - Industrial Equipment → Emergency power cutoff or speed reduction - -### Why Safety Island Matters for Functional Safety - -Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. - -How Safety Island Enhances Functional Safety -1. Acts as an Independent Redundant Safety Layer - - Even if the main system fails, it can still operate independently. -2. Supports ASIL-D Safety Level - - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. -3. Provides Independent Fault Detection and Recovery Mechanisms - - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. - - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. - -### Functional Safety in the Software Development Lifecycle - -Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. -For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. - -### Functional Safety Requirements in Software Development - -These practices ensure the software development process meets industry safety standards and can withstand system-level failures: -- Requirement Specification - - Clearly defining safety-critical requirements and conducting risk assessments. -- Safety-Oriented Programming - - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. -- Fault Handling Mechanisms - - Implementing redundancy design and health monitoring to handle anomalies. -- Testing and Verification - - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. -- Version Management and Change Control - - Using Git, JIRA, Polarion to track changes for safety audits. - -By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. - -This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index c32097ed7b..d9befbe3bf 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -6,9 +6,6 @@ weight: 5 layout: learningpathall --- - - - ## Functional safety: purpose and risk management principles diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md index 495d420c98..8d265bafe6 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md @@ -1,10 +1,6 @@ --- title: Prototype safety-critical isolation for autonomous driving systems on Neoverse -draft: true -cascade: - draft: true - minutes_to_complete: 60 who_is_this_for: This Learning Path is for experienced automotive engineers developing safety-critical systems. You'll learn how to accelerate ISO 26262-compliant development workflows using Arm-based cloud compute, containerized simulation, and DDS-based communication. From 603e47ca6a564324295524cd071e784b0164267b Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Wed, 23 Jul 2025 10:36:53 +0000 Subject: [PATCH 06/21] Rewriting --- .../1a_functional_safety.md | 22 ++-- .../openadkit2_safetyisolation/1b_purpose.md | 32 +++-- .../openadkit2_safetyisolation/1c_ISO26262 | 109 ------------------ .../openadkit2_safetyisolation/1c_ISO26262.md | 37 ++++++ .../1d_safety_island_arch.md | 59 +--------- 5 files changed, 74 insertions(+), 185 deletions(-) delete mode 100644 content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 create mode 100644 content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md index 60b2e2eb60..9c7c387153 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md @@ -1,25 +1,25 @@ --- -title: Functional safety for automotive software development +title: Why functional safety matters in software systems weight: 2 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Why functional safety matters +## Understand the role of functional safety in software development -Functional safety refers to a system's ability to detect potential faults and respond appropriately to ensure that the system remains in a safe state, preventing harm to individuals or damage to equipment. +Functional safety ensures that systems can detect faults and respond in ways that keep people and equipment safe. It helps prevent harm by ensuring that systems remain in a known, safe state, even when errors occur. -This is particularly important in automotive, autonomous driving, medical devices, industrial control, robotics and aerospace applications, where system failures can lead to severe consequences. +This concept is especially critical in domains like automotive, autonomous driving, medical devices, industrial control, robotics, and aerospace. In these systems, failures can have severe real-world consequences. -In software development, functional safety focuses on minimizing risks through software design, testing, and validation to ensure that critical systems operate in a predictable, reliable, and verifiable manner. +In software development, functional safety focuses on minimizing risks through careful design, rigorous testing, and thorough validation. The goal is to make sure that critical systems behave predictably, reliably, and verifiably, even under fault conditions. -This means developers must consider: +To design for functional safety, developers must consider: -- Error detection mechanisms -- Exception handling -- Redundancy design -- Development processes compliant with safety standards +- Error detection mechanisms +- Exception handling strategies +- Redundant system design +- Development processes that align with safety standards -In the following sections, you'll explore how to apply these principles throughout the software lifecycle, which ranges from risk assessment and architectural design to runtime isolation and compliance with ISO 26262. +In the following sections, you'll explore how to apply these principles throughout the software lifecycle, from early risk assessment and architectural design to runtime isolation and ISO 26262 compliance. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md index d47820b3e3..d5f156b58d 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md @@ -1,22 +1,36 @@ --- -title: Purpose and risk management principles +title: Understand functional safety risks weight: 3 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Functional safety: purpose and risk management principles +## Manage risk with functional safety principles + +At its core, functional safety is about managing risk and reducing the impact of system failures. + +In autonomous vehicles, for example, functional safety ensures that if sensor data is incorrect, the system can enter a safe state and prevent dangerous driving decisions. + +The three core objectives of functional safety are: + +- **Prevention** reduces the likelihood of errors through rigorous software development processes and testing. For example, electric vehicles monitor battery temperature to prevent overheating. + +- **Detection** quickly identifies errors using built-in diagnostic mechanisms, such as built-in self-test routines. + +- **Mitigation** controls the impact of failures to ensure the system stays safe, even when things go wrong. + +These three principles form the foundation for building safer, more reliable software systems. + +This approach is critical in systems like autonomous vehicles and medical devices, where failures can have serious consequences. + + + + + -The core of Functional Safety lies in risk management, which aims to reduce the impact of system failures. -In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a safe state, preventing incorrect driving decisions. -The three core objectives of Functional Safety are: -1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In electric vehicles, battery systems monitor temperature to prevent overheating. -2. Detection: Quickly identifying errors using built-in diagnostic mechanisms, such as built-in self-test. -3. Mitigation: Controlling the impact of failures to ensure the overall safety of the system. -This approach is critical in applications such as autonomous driving, flight control, and medical implants, where failures can result in severe consequences. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 deleted file mode 100644 index 11d99083e7..0000000000 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262 +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Explore ISO 26262 and ASIL levels -weight: 4 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -## ISO 26262: Automotive Functional Safety Standard - -ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. - -Key Concepts of ISO 26262: -- ASIL (Automotive Safety Integrity Level) - - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). - - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). -- HARA (Hazard Analysis and Risk Assessment) - - Analyzes hazards and assesses risks to determine necessary safety measures. -- Safety Mechanisms - - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. - -Typical Application Scenarios: -- Autonomous Driving Systems: - - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. -- Powertrain Control: - - Prevents braking system failures that could lead to loss of control. -- Battery Management System (BMS): - - Prevents battery overheating or excessive discharge in electric vehicles. - -### Common Use Cases of Functional Safety in Automotive - -- Autonomous Driving: - - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. - - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. - -- Powertrain Control: - - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. - - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. - -- Battery Management Systems (BMS): - - Protects EV batteries from overheating, overcharging, or deep discharge. - - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. - -These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. -A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. - -### Safety Island: Enabling Functional Safety in Autonomous Systems - -In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. - -The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. - -| Feature | General ECU | Safety Island | -|------------------------|----------------------------|--------------------------------------| -| Purpose | Comfort/non-safety logic | Safety-critical decision making | -| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | -| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | -| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | -| Fault Handling | Best-effort recovery | Deterministic safe-state response | - -This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. - -Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. - -Key Capabilities of Safety Island -- System Health Monitoring - - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. -- Fault Detection and Isolation - - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. -- Providing Essential Safety Functions - - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: - - Autonomous Vehicles → Safe stopping (fail-safe mode) - - Industrial Equipment → Emergency power cutoff or speed reduction - -### Why Safety Island Matters for Functional Safety - -Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. - -How Safety Island Enhances Functional Safety -1. Acts as an Independent Redundant Safety Layer - - Even if the main system fails, it can still operate independently. -2. Supports ASIL-D Safety Level - - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. -3. Provides Independent Fault Detection and Recovery Mechanisms - - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. - - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. - -### Functional Safety in the Software Development Lifecycle - -Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. -For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. - -### Functional Safety Requirements in Software Development - -These practices ensure the software development process meets industry safety standards and can withstand system-level failures: -- Requirement Specification - - Clearly defining safety-critical requirements and conducting risk assessments. -- Safety-Oriented Programming - - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. -- Fault Handling Mechanisms - - Implementing redundancy design and health monitoring to handle anomalies. -- Testing and Verification - - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. -- Version Management and Change Control - - Using Git, JIRA, Polarion to track changes for safety audits. - -By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. - -This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md new file mode 100644 index 0000000000..740aa8ac57 --- /dev/null +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md @@ -0,0 +1,37 @@ +--- +title: Apply ISO 26262 and ASIL levels +weight: 4 + +### FIXED, DO NOT MODIFY +layout: learningpathall +--- +## Understand ISO 26262 and safety integrity levels + +ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive safety lifecycle aligned with the V-model, covering phases from requirements to maintenance. + +## Key concepts in ISO 26262 + +- **ASIL (Automotive Safety Integrity Level)** ranks the safety criticality of components on a scale from A (lowest) to D (highest). For example, ASIL A might apply to a dashboard indicator failure, while ASIL D applies to a brake system malfunction. + +{{% notice Note %}}In practice, many OEMs default to ASIL D for systems with any potential for passenger harm, even if the statistical likelihood of failure is low.{{% /notice %}} + +- **HARA (Hazard Analysis and Risk Assessment)** identifies potential hazards and evaluates their risks to define the required safety goals and ASIL levels. + +- **Safety mechanisms** include techniques such as real-time fault detection, redundancy, and fallback modes like fail-safe and fail-operational behavior. + +## Apply ISO 26262 in real-world systems + +ISO 26262 applies to many safety-critical vehicle systems: + +- **Autonomous driving systems** must respond safely to sensor errors (such as LiDAR, radar, or camera faults). Functional safety ensures the vehicle can enter a safe state and avoid unsafe decisions. + +- **Powertrain control** systems monitor throttle and braking inputs. Safety mechanisms such as redundancy, plausibility checks, and overrides prevent unintended acceleration or loss of braking function. + +- **Battery management systems (BMS)** protect electric vehicle batteries from overheating, overcharging, or deep discharge. Built-in safety functions monitor temperature, balance voltage, and isolate faulty circuits to prevent thermal runaway. + +These systems require dedicated hardware and software architectures that enforce functional safety guarantees. One common solution is the **Safety Island**—an isolated compute domain used to run safety-critical control logic independently from the main system. + + + + + diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index d9befbe3bf..70f35c53bb 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -1,64 +1,11 @@ --- -title: Apply functional safety with Safety Island architecture +title: Use Safety Island architecture to ensure functional safety weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- - -## Functional safety: purpose and risk management principles - - -The core of Functional Safety lies in risk management, which aims to reduce the impact of system failures. - -In autonomous vehicles, Functional Safety ensures that if sensor data is incorrect, the system can enter a safe state, preventing incorrect driving decisions. - -The three core objectives of Functional Safety are: -1. Prevention: Reducing the likelihood of errors through rigorous software development processes and testing. In electric vehicles, battery systems monitor temperature to prevent overheating. -2. Detection: Quickly identifying errors using built-in diagnostic mechanisms, such as built-in self-test. -3. Mitigation: Controlling the impact of failures to ensure the overall safety of the system. - -This approach is critical in applications such as autonomous driving, flight control, and medical implants, where failures can result in severe consequences. - -### ISO 26262: Automotive Functional Safety Standard - -ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive V-model aligned safety lifecycle, covering all phases from requirement analysis, design, development, testing, to maintenance. - -Key Concepts of ISO 26262: -- ASIL (Automotive Safety Integrity Level) - - Evaluates the risk level of different system components (A, B, C, D, where D represents the highest safety requirement). - - For example: ASIL A can be Dashboard light failure (low risk) and ASIL D is Brake system failure (high risk). -- HARA (Hazard Analysis and Risk Assessment) - - Analyzes hazards and assesses risks to determine necessary safety measures. -- Safety Mechanisms - - Includes real-time error detection, system-level fault tolerance, and defined fail-safe or fail-operational fallback states. - -Typical Application Scenarios: -- Autonomous Driving Systems: - - Ensures that even if sensors (for example LiDAR, radar, cameras) provide faulty data, the vehicle will not make dangerous decisions. -- Powertrain Control: - - Prevents braking system failures that could lead to loss of control. -- Battery Management System (BMS): - - Prevents battery overheating or excessive discharge in electric vehicles. - -### Common Use Cases of Functional Safety in Automotive - -- Autonomous Driving: - - Ensures the vehicle can operate safely or enter a fail-safe state when sensors like LiDAR, radar, or cameras malfunction. - - Functional Safety enables real-time fault detection and fallback logic to prevent unsafe driving decisions. - -- Powertrain Control: - - Monitors throttle and brake signals to prevent unintended acceleration or braking loss. - - Includes redundancy, plausibility checks, and emergency overrides to maintain control under failure conditions. - -- Battery Management Systems (BMS): - - Protects EV batteries from overheating, overcharging, or deep discharge. - - Safety functions include temperature monitoring, voltage balancing, and relay cut-off mechanisms to prevent thermal runaway. - -These use cases highlight the need for a dedicated architectural layer that can enforce Functional Safety principles with real-time guarantees. -A widely adopted approach in modern automotive platforms is the Safety Island—an isolated compute domain designed to execute critical control logic independently of the main system. - -### Safety Island: Enabling Functional Safety in Autonomous Systems +## Implement safety-critical isolation with Safety Island architecture In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. @@ -86,7 +33,7 @@ Key Capabilities of Safety Island - Autonomous Vehicles → Safe stopping (fail-safe mode) - Industrial Equipment → Emergency power cutoff or speed reduction -### Why Safety Island Matters for Functional Safety +## Why Safety Island Matters for Functional Safety Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. From 43d68a8fc556cd4c6dce2d2b863123addb6bf441 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Wed, 23 Jul 2025 11:07:31 +0000 Subject: [PATCH 07/21] Updates --- .../openadkit2_safetyisolation/1b_purpose.md | 13 ++++++++++--- .../1d_safety_island_arch.md | 4 ++-- .../4_multiinstance_executing.md | 10 +++++----- 3 files changed, 17 insertions(+), 10 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md index d5f156b58d..086dea784d 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md @@ -10,7 +10,7 @@ layout: learningpathall At its core, functional safety is about managing risk and reducing the impact of system failures. -In autonomous vehicles, for example, functional safety ensures that if sensor data is incorrect, the system can enter a safe state and prevent dangerous driving decisions. +In autonomous vehicles, for example, functional safety ensures that if sensor data is incorrect, the system can transition into a safe state and avoid unsafe driving behavior. The three core objectives of functional safety are: @@ -20,11 +20,18 @@ The three core objectives of functional safety are: - **Mitigation** controls the impact of failures to ensure the system stays safe, even when things go wrong. -These three principles form the foundation for building safer, more reliable software systems. +In practice, these principles might be implemented through: -This approach is critical in systems like autonomous vehicles and medical devices, where failures can have serious consequences. +- Redundant sensor fusion code paths +- Timeout mechanisms for control loops +- Watchdog timers that reset components on fault detection +- Safe-state logic baked into actuator control routines + +These three principles of prevention, detection, and mitigation form the foundation for building safer, more reliable software systems. +This approach is critical in systems like autonomous vehicles and medical devices, where failures can have serious consequences. +In the next step, you’ll explore how functional safety principles are formalized through safety standards like ISO 26262 and applied to real-world systems. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index 70f35c53bb..efe59e2938 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -7,7 +7,7 @@ layout: learningpathall --- ## Implement safety-critical isolation with Safety Island architecture -In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (e.g., braking, steering) with strong isolation, redundancy, and determinism. +In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. @@ -25,7 +25,7 @@ Safety Island is an independent safety subsystem separate from the main processo Key Capabilities of Safety Island - System Health Monitoring - - Continuously monitors the operational status of the main processor (e.g., ADAS control unit, ECU) and detects potential errors or anomalies. + - Continuously monitors the operational status of the main processor (for example, ADAS control unit, ECU) and detects potential errors or anomalies. - Fault Detection and Isolation - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. - Providing Essential Safety Functions diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index 3357c153c1..3ce8105ebd 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -1,5 +1,5 @@ --- -title: Executing OpenAD Kit in a Distributed ROS 2 Instances +title: Execute OpenAD Kit across distributed ROS 2 instances weight: 9 @@ -7,14 +7,14 @@ weight: 9 layout: learningpathall --- -### Demonstrating the Distributed OpenAD Kit in Action +## Run OpenAD Kit on distributed ROS 2 instances In this section, you’ll bring all the previous setup together and execute the full OpenAD Kit demo across two Arm-based instances. OpenAD Kit is an open-source reference design for autonomous driving workloads on Arm. It demonstrates how Autoware modules can be deployed on scalable infrastructure, whether on a single machine or split across multiple compute nodes. -#### Preparing the Execution Scripts +## Prepare the execution scripts This setup separates the simulation/visualization environment from the planning-control logic, allowing you to explore how ROS 2 nodes communicate over a distributed system using DDS (Data Distribution Service). @@ -71,7 +71,7 @@ You can also find the prepared launch scripts `opad_planning.sh` and `opad_sim_v These scripts encapsulate the required environment variables and container commands for each role. -#### Running the Distributed OpenAD Kit Demo +#### Run the distributed OpenAD Kit demo On the Planning-Control node, execute: @@ -92,7 +92,7 @@ http://[Visualizer public IP address]:6080/vnc.html You can open this link in a browser to observe the demo behavior, which will closely resemble the output from the [previous learning path](http://learn.arm.com/learning-paths/automotive/openadkit1_container/4_run_openadkit/). -![img3 alt-text#center](split_aws_run.gif "Figure 4: Simulation") +![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS](split_aws_run.gif "Figure 4: Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") The containers are now distributed across two separate instances, enabling real-time, cross-node communication. Behind the scenes, this architecture demonstrates how DDS manages low-latency, peer-to-peer data exchange in a distributed ROS 2 environment. From 40b4ae2bb5b0821084dabc055ff33b477f00150f Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Wed, 23 Jul 2025 16:57:54 +0000 Subject: [PATCH 08/21] Refinements, consistency checks, and rewriting. --- .../1a_functional_safety.md | 4 +- .../openadkit2_safetyisolation/1b_purpose.md | 6 +- .../openadkit2_safetyisolation/1c_ISO26262.md | 8 +-- .../1d_safety_island_arch.md | 61 ++++++++++--------- .../1e_implement functional_safety.md | 39 ++++++------ .../2_data_distribution_service.md | 22 ++++--- .../4_multiinstance_executing.md | 20 +++--- 7 files changed, 86 insertions(+), 74 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md index 9c7c387153..f40bbd93c2 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md @@ -8,7 +8,7 @@ layout: learningpathall ## Understand the role of functional safety in software development -Functional safety ensures that systems can detect faults and respond in ways that keep people and equipment safe. It helps prevent harm by ensuring that systems remain in a known, safe state, even when errors occur. +Functional safety helps systems detect faults and respond in ways that keep people and equipment safe. It helps prevent harm by ensuring that systems remain in a known, safe state, even when errors occur. This concept is especially critical in domains like automotive, autonomous driving, medical devices, industrial control, robotics, and aerospace. In these systems, failures can have severe real-world consequences. @@ -22,4 +22,4 @@ To design for functional safety, developers must consider: - Development processes that align with safety standards -In the following sections, you'll explore how to apply these principles throughout the software lifecycle, from early risk assessment and architectural design to runtime isolation and ISO 26262 compliance. +In the following sections, you'll learn how to apply these principles throughout the software lifecycle, from early risk assessment and architectural design to runtime isolation and ISO 26262 compliance. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md index 086dea784d..267c4679f1 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md @@ -15,9 +15,7 @@ In autonomous vehicles, for example, functional safety ensures that if sensor da The three core objectives of functional safety are: - **Prevention** reduces the likelihood of errors through rigorous software development processes and testing. For example, electric vehicles monitor battery temperature to prevent overheating. - - **Detection** quickly identifies errors using built-in diagnostic mechanisms, such as built-in self-test routines. - - **Mitigation** controls the impact of failures to ensure the system stays safe, even when things go wrong. In practice, these principles might be implemented through: @@ -25,9 +23,9 @@ In practice, these principles might be implemented through: - Redundant sensor fusion code paths - Timeout mechanisms for control loops - Watchdog timers that reset components on fault detection -- Safe-state logic baked into actuator control routines +- Safe-state logic embedded in actuator control routines -These three principles of prevention, detection, and mitigation form the foundation for building safer, more reliable software systems. +Together, prevention, detection, and mitigation form the foundation for building safer, more reliable software systems. This approach is critical in systems like autonomous vehicles and medical devices, where failures can have serious consequences. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md index 740aa8ac57..d1931f92bf 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md @@ -7,15 +7,15 @@ layout: learningpathall --- ## Understand ISO 26262 and safety integrity levels -ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive safety lifecycle aligned with the V-model, covering phases from requirements to maintenance. +ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive safety lifecycle aligned with the V-model, that covers everything from initial requirements to ongoing maintenance. ## Key concepts in ISO 26262 -- **ASIL (Automotive Safety Integrity Level)** ranks the safety criticality of components on a scale from A (lowest) to D (highest). For example, ASIL A might apply to a dashboard indicator failure, while ASIL D applies to a brake system malfunction. +- **Automotive Safety Integrity Level (ASIL)** ranks the safety criticality of components on a scale from A (lowest) to D (highest). For example, ASIL A might apply to a dashboard indicator failure, while ASIL D applies to a brake system malfunction. {{% notice Note %}}In practice, many OEMs default to ASIL D for systems with any potential for passenger harm, even if the statistical likelihood of failure is low.{{% /notice %}} -- **HARA (Hazard Analysis and Risk Assessment)** identifies potential hazards and evaluates their risks to define the required safety goals and ASIL levels. +- **Hazard Analysis and Risk Assessment (HARA)** identifies potential hazards and evaluates their risks to define the required safety goals and ASIL levels. - **Safety mechanisms** include techniques such as real-time fault detection, redundancy, and fallback modes like fail-safe and fail-operational behavior. @@ -29,7 +29,7 @@ ISO 26262 applies to many safety-critical vehicle systems: - **Battery management systems (BMS)** protect electric vehicle batteries from overheating, overcharging, or deep discharge. Built-in safety functions monitor temperature, balance voltage, and isolate faulty circuits to prevent thermal runaway. -These systems require dedicated hardware and software architectures that enforce functional safety guarantees. One common solution is the **Safety Island**—an isolated compute domain used to run safety-critical control logic independently from the main system. +These systems require dedicated hardware and software architectures that enforce functional safety guarantees. One common solution is the **Safety Island**, which is an isolated compute domain used to run safety-critical control logic independently from the main system. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index efe59e2938..e0267b9848 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -1,48 +1,53 @@ --- -title: Use Safety Island architecture to ensure functional safety +title: Implement safety-critical isolation with Safety Island architecture weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Implement safety-critical isolation with Safety Island architecture +## Isolate safety-critical logic using a Safety Island -In automotive systems, a General ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation, whereas a Safety Island is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. +In automotive systems, a general ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation. -The table below compares the characteristics of a General ECU and a Safety Island in terms of their role in supporting Functional Safety. +A Safety Island, by contrast, is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. + +The table below compares the characteristics of a general ECU and a Safety Island in terms of their role in supporting functional safety. | Feature | General ECU | Safety Island | |------------------------|----------------------------|--------------------------------------| | Purpose | Comfort/non-safety logic | Safety-critical decision making | -| OS/Runtime | Linux, Android | RTOS, Hypervisor, or bare-metal | -| Isolation | Soft partitioning | Hard isolation (hardware-enforced) | -| Functional Safety Req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | -| Fault Handling | Best-effort recovery | Deterministic safe-state response | +| OS/runtime | Linux, Android | RTOS, hypervisor, or bare-metal | +| Isolation | Soft partitioning | Hardware-enforced isolation | +| Functional safety req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | +| Fault handling | Best-effort recovery | Deterministic safe-state response | + +{{% notice Tip %}} +Safety Islands are often implemented as lockstep cores or separate MCUs that run on real-time operating systems (RTOS), offering guaranteed performance under fault conditions. +{{% /notice %}} This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. -Safety Island is an independent safety subsystem separate from the main processor. It is responsible for monitoring and managing system safety. If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. +If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. + +## Key capabilities of Safety Island +- **System health monitoring** + - Continuously monitors the operational status of the main processor (for example, the ADAS control unit) and detects potential errors or anomalies. +- **Fault detection and isolation** + - Independently detects failures and initiates emergency handling for overheating, execution faults, or unresponsiveness. +- **Provides essential safety functions**, even if the main system crashes, the Safety Island still executes minimal safety operations, such as: + - Autonomous Vehicles → safe stopping (fail-safe mode) + - Industrial Equipment → emergency power cutoff or speed reduction -Key Capabilities of Safety Island -- System Health Monitoring - - Continuously monitors the operational status of the main processor (for example, ADAS control unit, ECU) and detects potential errors or anomalies. -- Fault Detection and Isolation - - Independently evaluates and initiates emergency handling if the main processing unit encounters errors, overheating, computational failures, or unresponsiveness. -- Providing Essential Safety Functions - - Even if the main system crashes, Safety Island can still execute minimal safety operations, such as: - - Autonomous Vehicles → Safe stopping (fail-safe mode) - - Industrial Equipment → Emergency power cutoff or speed reduction +## Why Safety Island matters for functional safety -## Why Safety Island Matters for Functional Safety +Safety Island helps systems respond to high-risk scenarios and reduces the likelihood of catastrophic failures. -Safety Island plays a critical role in Functional Safety by ensuring that the system can handle high-risk scenarios and minimize catastrophic failures. +- **Acts as an independent redundant safety layer** + - Operates safety logic independently of the main processor -How Safety Island Enhances Functional Safety -1. Acts as an Independent Redundant Safety Layer - - Even if the main system fails, it can still operate independently. -2. Supports ASIL-D Safety Level - - Monitors ECU health status and executes emergency safety strategies, such as emergency braking. -3. Provides Independent Fault Detection and Recovery Mechanisms - - Fail-Safe: Activates a safe mode, such as limiting vehicle speed or switching to manual control. - - Fail-Operational: Ensures that high-safety applications, such as aerospace systems, can continue operating under certain conditions. +- **Supports ASIL-D safety level** + - Enables the system to meet the highest ISO 26262 requirements for critical operations +- **Provides independent fault detection and recovery mechanisms** + - *Fail-safe*: activates a minimal-risk mode, such as limiting vehicle speed or switching to manual control + - *Fail-operational*: allows high-integrity systems, such as those in aerospace or autonomous driving, to continue functioning under fault conditions diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md index 92fbcabb10..b12e9a66dc 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md @@ -6,25 +6,30 @@ weight: 6 layout: learningpathall --- -## Functional Safety in the Software Development Lifecycle +## The software development lifecycle -Functional Safety impacts both hardware and software development, particularly in areas such as requirement changes, version management, and testing validation. -For example, in ASIL-D level applications, every code modification requires a complete impact analysis and regression testing to ensure that new changes do not introduce additional risks. +Functional Safety affects both hardware and software development, particularly in areas such as requirement changes, version control, and test validation. For example, in ASIL-D level applications, every code change must go through a full impact analysis and regression testing to ensure it doesn't introduce new risks. -### Functional Safety Requirements in Software Development +## Software development practices for functional safety -These practices ensure the software development process meets industry safety standards and can withstand system-level failures: -- Requirement Specification - - Clearly defining safety-critical requirements and conducting risk assessments. -- Safety-Oriented Programming - - Following MISRA C, CERT C/C++ standards and using static analysis tools to detect errors. -- Fault Handling Mechanisms - - Implementing redundancy design and health monitoring to handle anomalies. -- Testing and Verification - - Using Hardware-in-the-Loop (HIL) testing to ensure software safety in real hardware environments. -- Version Management and Change Control - - Using Git, JIRA, Polarion to track changes for safety audits. +These practices ensure that software meets industry standards and can withstand system-level failures: +- **Define requirements clearly** + - Specify safety-critical requirements and conduct formal risk assessments. -By establishing an ASIL Partitioning software development environment and leveraging SOAFEE technologies, you can enhance software consistency and maintainability in Functional Safety applications. +- **Follow safety-oriented programming standards** + - Use MISRA C or CERT C/C++ and static analysis tools to detect unsafe behavior. -This Learning Path follows [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/) and introduces Functional Safety design practices from the earliest development stages. \ No newline at end of file +- **Implement fault-handling mechanisms** + - Use redundancy, health monitoring, and fail-safe logic to manage faults gracefully. + +- **Test and verify rigorously** + - Use Hardware-in-the-Loop (HIL) testing to validate behavior under realistic conditions. + +- **Track changes with version control and audits** + - Use tools like Git, JIRA, or Polarion to manage revisions and maintain traceability for audits. + +By building an ASIL-partitioned development environment and adopting SOAFEE technologies, you can improve software maintainability and meet functional safety requirements more consistently. + +{{% notice Note %}} +This Learning Path builds on [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/). It introduces functional safety practices from the earliest stages of software development. +{{% /notice %}} diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md index 4865aa88f0..88864a4e20 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md @@ -1,12 +1,12 @@ --- -title: How to Use Data Distribution Service (DDS) +title: How to use Data Distribution Service (DDS) weight: 7 ### FIXED, DO NOT MODIFY layout: learningpathall --- -### Introduction to DDS +## Introduction to DDS Data Distribution Service (DDS) is a real-time, high-performance middleware designed for distributed systems. It is particularly valuable in automotive software development, including applications such as autonomous driving (AD) and advanced driver assistance systems (ADAS). @@ -16,7 +16,12 @@ In modern vehicles, multiple sensors such as LiDAR, radar, and cameras must cont DDS ensures these components share data seamlessly and in real time, both within the vehicle and across infrastructure such as V2X systems, including traffic lights and road sensors. -### Why Automotive Software Needs DDS +{{% notice Tip %}} +To get started with open-source DDS on Arm platforms, check out the [Installation Guide for CycloneDDS](https://learn.arm.com/install-guides/cyclonedds) on how to install open-source DDS on an Arm platform. +{{% /notice %}} + + +## Why automotive software needs DDS Next-generation automotive software architectures, such as SOAFEE, depend on deterministic, distributed communication. Traditional client-server models introduce latency and create single points of failure. In contrast, DDS uses a publish-subscribe model that enables direct, peer-to-peer communication across system components. @@ -26,7 +31,7 @@ Additionally, DDS provides a flexible Quality of Service (QoS) configuration, al These capabilities make DDS an essential backbone for autonomous vehicle stacks, where real-time sensor fusion and control coordination are critical for safety and performance. -### DDS Architecture and Operation +## DDS architecture and operation DDS uses a data-centric publish-subscribe (DCPS) model, allowing producers and consumers of data to communicate without direct dependencies. This modular approach enhances system flexibility and maintainability, making it well suited for complex automotive environments. @@ -41,7 +46,7 @@ Each domain contains multiple topics, representing specific data types such as v For example, in an autonomous vehicle, LiDAR, radar, and cameras continuously generate large amounts of sensor data. The perception module subscribes to these sensor topics, processes the data, and then publishes detected objects and road conditions to other components like path planning and motion control. Since DDS automatically handles participant discovery and message distribution, engineers do not need to manually configure communication paths, reducing development complexity. -### Real-World Use in Autonomous Driving +## Real-world use in autonomous driving DDS is widely used in autonomous driving systems, where real-time data exchange is crucial. A typical use case involves high-frequency sensor data transmission and decision-making coordination between vehicle subsystems. @@ -53,7 +58,7 @@ For example, Autoware, an open-source autonomous driving software stack, uses DD The Perception stack publishes detected objects from LiDAR and camera sensors to a shared topic, which is then consumed by the Planning module in real-time. Using DDS allows each subsystem to scale independently while preserving low-latency and deterministic communication. -### Publish-Subscribe Model and Data Transmission +## Publish-subscribe model and data transmission Let’s explore how DDS’s publish-subscribe model fundamentally differs from traditional communication methods in terms of scalability, latency, and reliability. @@ -68,7 +73,7 @@ DDS supports multiple transport mechanisms to optimize communication efficiency: * UDP or TCP/IP is used for inter-device communication, such as V2X applications where vehicles exchange safety-critical messages. * Automatic participant discovery eliminates the need for manual configuration, allowing DDS nodes to detect and establish connections dynamically. -#### Comparison of DDS and Traditional Communication Methods +## Compare DDS with traditional communication models The following table highlights how DDS improves upon traditional client-server communication patterns in the context of real-time automotive applications: @@ -84,7 +89,6 @@ These features make DDS a highly adaptable solution for automotive software engi In this section, you learned how DDS enables low-latency, scalable, and fault-tolerant communication for autonomous vehicle systems. -Its data-centric publish-subscribe architecture eliminates the limitations of traditional client-server models and forms the backbone of modern automotive software frameworks such as ROS 2 and SOAFEE. +Its data-centric publish-subscribe architecture removes the limitations of traditional client-server models and forms the backbone of modern automotive software frameworks like ROS 2 and SOAFEE. -To get started with open-source DDS on Arm platforms, refer to this [installation guide for Cyclonedds](https://learn.arm.com/install-guides/cyclonedds) on how to install open-source DDS on an Arm platform. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index 3ce8105ebd..3bbc8e8fe1 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -7,14 +7,13 @@ weight: 9 layout: learningpathall --- -## Run OpenAD Kit on distributed ROS 2 instances +## What this distributed demo shows you In this section, you’ll bring all the previous setup together and execute the full OpenAD Kit demo across two Arm-based instances. -OpenAD Kit is an open-source reference design for autonomous driving workloads on Arm. -It demonstrates how Autoware modules can be deployed on scalable infrastructure, whether on a single machine or split across multiple compute nodes. +OpenAD Kit is an open-source reference design for autonomous driving workloads on Arm. It demonstrates how Autoware modules can be deployed on scalable infrastructure, either on a single machine or distributed across multiple compute nodes. -## Prepare the execution scripts +## Prepare launch scripts on both instances This setup separates the simulation/visualization environment from the planning-control logic, allowing you to explore how ROS 2 nodes communicate over a distributed system using DDS (Data Distribution Service). @@ -24,7 +23,7 @@ On each instance, copy the appropriate launch script into the `openadkit_demo.au {{< tabpane code=true >}} {{< tab header="Planning-Control" language="bash">}} - !/bin/bash + #!/bin/bash # Configure the environment variables export SCRIPT_DIR=/home/ubuntu/openadkit_demo.autoware/docker export CONF_FILE_PASS=$SCRIPT_DIR/etc/simulation/config/pass_static_obstacle_avoidance.param.yaml @@ -40,7 +39,7 @@ On each instance, copy the appropriate launch script into the `openadkit_demo.au TIMEOUT=120 CONF_FILE=$CONF_FILE_PASS docker compose -f "$SCRIPT_DIR/docker-compose-2ins.yml" up planning-control -d {{< /tab >}} - {{< tab header="Visualizer & Simulator" language="bash">}} + {{< tab header="Visualizer and simulator" language="bash">}} #!/bin/bash export SCRIPT_DIR=/home/ubuntu/openadkit_demo.autoware/docker @@ -71,7 +70,7 @@ You can also find the prepared launch scripts `opad_planning.sh` and `opad_sim_v These scripts encapsulate the required environment variables and container commands for each role. -#### Run the distributed OpenAD Kit demo +## Run the distributed OpenAD Kit demo On the Planning-Control node, execute: @@ -94,9 +93,10 @@ You can open this link in a browser to observe the demo behavior, which will clo ![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS](split_aws_run.gif "Figure 4: Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") -The containers are now distributed across two separate instances, enabling real-time, cross-node communication. -Behind the scenes, this architecture demonstrates how DDS manages low-latency, peer-to-peer data exchange in a distributed ROS 2 environment. +You’ve now run the OpenAD Kit across two nodes with separated control and visualization roles. DDS enabled real-time communication between the ROS 2 nodes across the network, with synchronized behavior between the planning and simulation components. + +The containers are now distributed across two separate instances, enabling real-time, cross-node communication. Behind the scenes, this architecture demonstrates how DDS manages low-latency, peer-to-peer data exchange in a distributed ROS 2 environment. To support demonstration and validation, the simulator is configured to run three times sequentially, giving you multiple opportunities to observe how data flows between nodes and verify that communication remains stable across each cycle. -Now that you’ve seen the distributed system in action, consider exploring different QoS settings, network conditions, or even adding a third node to expand the architecture further. +Now that you've seen the distributed system in action, try adjusting QoS settings, simulating network delays, or adding a third node to expand the architecture. From aff240a03fb1a3a3ab314bf60d80d51ded4bc609 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Wed, 23 Jul 2025 21:47:55 +0000 Subject: [PATCH 09/21] Updates --- .../1a_functional_safety.md | 6 +-- .../openadkit2_safetyisolation/1b_purpose.md | 8 ++-- .../openadkit2_safetyisolation/1c_ISO26262.md | 10 +++-- .../1d_safety_island_arch.md | 40 +++++++++---------- .../1e_implement functional_safety.md | 2 +- .../2_data_distribution_service.md | 5 ++- .../4_multiinstance_executing.md | 6 +-- 7 files changed, 39 insertions(+), 38 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md index f40bbd93c2..9848838044 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1a_functional_safety.md @@ -6,11 +6,11 @@ weight: 2 layout: learningpathall --- -## Understand the role of functional safety in software development +## What functional safety means for developers -Functional safety helps systems detect faults and respond in ways that keep people and equipment safe. It helps prevent harm by ensuring that systems remain in a known, safe state, even when errors occur. +Functional safety helps systems detect faults and respond in ways that keep people and equipment safe. It ensures that even when errors occur, the system transitions into a known, safe state to prevent harm. -This concept is especially critical in domains like automotive, autonomous driving, medical devices, industrial control, robotics, and aerospace. In these systems, failures can have severe real-world consequences. +This concept is foundational in domains like automotive, autonomous driving, medical devices, industrial control, robotics, and aerospace. In these systems, failures can have severe real-world consequences. In software development, functional safety focuses on minimizing risks through careful design, rigorous testing, and thorough validation. The goal is to make sure that critical systems behave predictably, reliably, and verifiably, even under fault conditions. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md index 267c4679f1..7363e87f80 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1b_purpose.md @@ -10,13 +10,13 @@ layout: learningpathall At its core, functional safety is about managing risk and reducing the impact of system failures. -In autonomous vehicles, for example, functional safety ensures that if sensor data is incorrect, the system can transition into a safe state and avoid unsafe driving behavior. +In autonomous vehicles, for example, functional safety ensures that if sensors produce unreliable or conflicting input, the vehicle can fall back to a known-safe state and maintain control. The three core objectives of functional safety are: - **Prevention** reduces the likelihood of errors through rigorous software development processes and testing. For example, electric vehicles monitor battery temperature to prevent overheating. -- **Detection** quickly identifies errors using built-in diagnostic mechanisms, such as built-in self-test routines. -- **Mitigation** controls the impact of failures to ensure the system stays safe, even when things go wrong. +- **Detection** quickly identifies errors using built-in diagnostic mechanisms, such as self-test routines. +- **Mitigation** controls the impact of failures to ensure the system stays safe, even when something goes wrong. In practice, these principles might be implemented through: @@ -27,8 +27,6 @@ In practice, these principles might be implemented through: Together, prevention, detection, and mitigation form the foundation for building safer, more reliable software systems. -This approach is critical in systems like autonomous vehicles and medical devices, where failures can have serious consequences. - In the next step, you’ll explore how functional safety principles are formalized through safety standards like ISO 26262 and applied to real-world systems. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md index d1931f92bf..57d48a7d74 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md @@ -5,20 +5,22 @@ weight: 4 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Understand ISO 26262 and safety integrity levels +## What ISO 26262 and ASIL levels mean for developers -ISO 26262 is a functional safety standard specifically for automotive electronics and software systems. It defines a comprehensive safety lifecycle aligned with the V-model, that covers everything from initial requirements to ongoing maintenance. +ISO 26262 is a functional safety standard for automotive electronics and software systems. It defines a structured safety lifecycle aligned with the V-model, spanning everything from initial requirements to final validation and maintenance. + +The V-model is a development framework where each design phase is paired with a corresponding test phase. This structure makes it easier to trace safety requirements from early specifications through to system verification. ## Key concepts in ISO 26262 - **Automotive Safety Integrity Level (ASIL)** ranks the safety criticality of components on a scale from A (lowest) to D (highest). For example, ASIL A might apply to a dashboard indicator failure, while ASIL D applies to a brake system malfunction. -{{% notice Note %}}In practice, many OEMs default to ASIL D for systems with any potential for passenger harm, even if the statistical likelihood of failure is low.{{% /notice %}} - - **Hazard Analysis and Risk Assessment (HARA)** identifies potential hazards and evaluates their risks to define the required safety goals and ASIL levels. - **Safety mechanisms** include techniques such as real-time fault detection, redundancy, and fallback modes like fail-safe and fail-operational behavior. +{{% notice Note %}}In practice, many OEMs default to ASIL D for systems with any potential for passenger harm, even if the statistical likelihood of failure is low.{{% /notice %}} + ## Apply ISO 26262 in real-world systems ISO 26262 applies to many safety-critical vehicle systems: diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index e0267b9848..5f3be175ab 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -1,46 +1,44 @@ --- -title: Implement safety-critical isolation with Safety Island architecture +title: Implement safety-critical isolation using safety island architecture weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## Isolate safety-critical logic using a Safety Island +## How safety islands support functional safety in software systems -In automotive systems, a general ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation. +In automotive systems, a non-safety ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation. -A Safety Island, by contrast, is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. +A safety island, by contrast, is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. -The table below compares the characteristics of a general ECU and a Safety Island in terms of their role in supporting functional safety. +The table below compares the characteristics of an ECU and a safety island in terms of their role in supporting functional safety. -| Feature | General ECU | Safety Island | +| Feature | ECU | Safety island | |------------------------|----------------------------|--------------------------------------| | Purpose | Comfort/non-safety logic | Safety-critical decision making | | OS/runtime | Linux, Android | RTOS, hypervisor, or bare-metal | | Isolation | Soft partitioning | Hardware-enforced isolation | -| Functional safety req | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | +| Functional safety requirement | None to moderate | ISO 26262 ASIL-B to ASIL-D compliant | | Fault handling | Best-effort recovery | Deterministic safe-state response | -{{% notice Tip %}} -Safety Islands are often implemented as lockstep cores or separate MCUs that run on real-time operating systems (RTOS), offering guaranteed performance under fault conditions. -{{% /notice %}} +This comparison shows why safety-critical software depends on dedicated hardware domains to meet functional safety goals. -This contrast highlights why safety-focused software needs a dedicated hardware domain with certified execution behavior. +If the main processor fails or becomes inoperable, a safety island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. -If the main processor fails or becomes inoperable, Safety Island can take over critical safety functions such as deceleration, stopping, and fault handling to prevent catastrophic system failures. +{{% notice Tip %}} +Safety islands are often implemented as lockstep cores or separate MCUs that run on real-time operating systems (RTOS), offering guaranteed performance under fault conditions. +{{% /notice %}} -## Key capabilities of Safety Island -- **System health monitoring** - - Continuously monitors the operational status of the main processor (for example, the ADAS control unit) and detects potential errors or anomalies. -- **Fault detection and isolation** - - Independently detects failures and initiates emergency handling for overheating, execution faults, or unresponsiveness. -- **Provides essential safety functions**, even if the main system crashes, the Safety Island still executes minimal safety operations, such as: +## Key capabilities of a safety island +- **System health monitoring** continuously monitors the operational status of the main processor (for example, the ADAS control unit) and detects potential errors or anomalies +- **Fault detection and isolation** independently detects failures and initiates emergency handling for overheating, execution faults, or unresponsiveness +- **Essential safety functions conitnue to operate**, even if the main system crashes. A safety island can execute fallback operations, such as: - Autonomous Vehicles → safe stopping (fail-safe mode) - Industrial Equipment → emergency power cutoff or speed reduction -## Why Safety Island matters for functional safety +## Why safety island matters for functional safety -Safety Island helps systems respond to high-risk scenarios and reduces the likelihood of catastrophic failures. +A safety island helps systems respond to high-risk scenarios and reduces the likelihood of catastrophic failures. - **Acts as an independent redundant safety layer** - Operates safety logic independently of the main processor @@ -51,3 +49,5 @@ Safety Island helps systems respond to high-risk scenarios and reduces the likel - **Provides independent fault detection and recovery mechanisms** - *Fail-safe*: activates a minimal-risk mode, such as limiting vehicle speed or switching to manual control - *Fail-operational*: allows high-integrity systems, such as those in aerospace or autonomous driving, to continue functioning under fault conditions + +Safety islands play a key role in enabling ISO 26262 compliance by isolating safety-critical logic from general-purpose processing. They're a proven solution for improving system determinism, fault tolerance, and fallback behavior. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md index b12e9a66dc..60b53a465b 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md @@ -28,7 +28,7 @@ These practices ensure that software meets industry standards and can withstand - **Track changes with version control and audits** - Use tools like Git, JIRA, or Polarion to manage revisions and maintain traceability for audits. -By building an ASIL-partitioned development environment and adopting SOAFEE technologies, you can improve software maintainability and meet functional safety requirements more consistently. +Building an ASIL-partitioned development environment and adopting SOAFEE technologies can help improve software maintainability and ensure consistent compliance with functional safety standards. {{% notice Note %}} This Learning Path builds on [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/). It introduces functional safety practices from the earliest stages of software development. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md index 88864a4e20..0f1b7145b7 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md @@ -10,7 +10,7 @@ layout: learningpathall Data Distribution Service (DDS) is a real-time, high-performance middleware designed for distributed systems. It is particularly valuable in automotive software development, including applications such as autonomous driving (AD) and advanced driver assistance systems (ADAS). -DDS offers a decentralized architecture that enables scalable, low-latency, and reliable data exchange, making it ideal for managing high-frequency sensor streams. +DDS uses a decentralized architecture that supports scalable, low-latency, and reliable data exchange, which is ideal for managing high-frequency sensor streams. In modern vehicles, multiple sensors such as LiDAR, radar, and cameras must continuously communicate with compute modules. @@ -87,8 +87,9 @@ The following table highlights how DDS improves upon traditional client-server c These features make DDS a highly adaptable solution for automotive software engineers seeking to develop scalable, real-time communication frameworks. -In this section, you learned how DDS enables low-latency, scalable, and fault-tolerant communication for autonomous vehicle systems. +DDS is a critical building block in distributed automotive systems. By enabling scalable, low-latency communication and fault tolerance, it powers real-time coordination in modern architectures like ROS 2, SOAFEE, and Autoware. Its data-centric publish-subscribe architecture removes the limitations of traditional client-server models and forms the backbone of modern automotive software frameworks like ROS 2 and SOAFEE. + diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index 3bbc8e8fe1..7bb1696fff 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -93,10 +93,10 @@ You can open this link in a browser to observe the demo behavior, which will clo ![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS](split_aws_run.gif "Figure 4: Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") -You’ve now run the OpenAD Kit across two nodes with separated control and visualization roles. DDS enabled real-time communication between the ROS 2 nodes across the network, with synchronized behavior between the planning and simulation components. +You’ve now run the OpenAD Kit across two nodes with separated control and visualization roles. DDS enabled real-time, peer-to-peer communication between the ROS 2 nodes, supporting synchronized behavior across the planning and simulation components deployed on two separate instances. The containers are now distributed across two separate instances, enabling real-time, cross-node communication. Behind the scenes, this architecture demonstrates how DDS manages low-latency, peer-to-peer data exchange in a distributed ROS 2 environment. -To support demonstration and validation, the simulator is configured to run three times sequentially, giving you multiple opportunities to observe how data flows between nodes and verify that communication remains stable across each cycle. +The simulator runs three times by default, giving you multiple chances to observe data flow and verify stable communication between nodes. -Now that you've seen the distributed system in action, try adjusting QoS settings, simulating network delays, or adding a third node to expand the architecture. +Now that you’ve seen the distributed system in action, try modifying QoS settings, simulating network conditions, or scaling to a third node to explore more complex configurations. From e5cd519b1aa463a38048d3068a0d4e55d53be1d1 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Wed, 23 Jul 2025 21:58:34 +0000 Subject: [PATCH 10/21] Updates --- .../3_container_spliting.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md index b65a553c4f..1620062325 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md @@ -1,12 +1,12 @@ --- -title: Split into multiple cloud container instances +title: Deploy OpenAD Kit across multiple cloud instances weight: 8 ### FIXED, DO NOT MODIFY layout: learningpathall --- -### System Architecture and Component Design +## Refactor OpenAD Kit for distributed deployment Now that you’ve explored the concept of a Safety Island, a dedicated subsystem responsible for executing safety-critical control logic, and learned how DDS (Data Distribution Service) enables real-time, distributed communication, you’ll refactor the original OpenAD Kit architecture into a multi-instance deployment. @@ -19,7 +19,7 @@ In this session, you will split the simulation and visualization stack from the These nodes communicate using ROS 2 with DDS as the middleware layer, ensuring low-latency and fault-tolerant data exchange between components. -### Architectural Benefits +## Architectural Benefits This architecture brings several practical benefits: @@ -37,7 +37,7 @@ With containerized separation, you can build, test, and deploy each module indep ![img1 alt-text#center](aws_example.jpg "Figure 1: Split instance example in AWS") -### Networking Setting +## Configure networking for DDS communication To begin, launch two Arm-based VM instances. AWS EC2 is used, but you can use any Arm instances. @@ -58,19 +58,19 @@ Within the EC2 Security Group settings: - Add an inbound rule that allows all traffic from the same Security Group by setting the source to the security group itself. - Outbound traffic is typically allowed by default and usually does not require changes. -![img2 alt-text#center](security_group.jpg "Figure 2: AWS Security Group Setting") +![img2 alt-text#center](security_group.jpg "AWS Security Group Setting") This configuration allows automatic discovery and peer-to-peer communication between DDS participants across the two instances. Once both systems are operational, record the private IP addresses of each instance. You will need them when configuring CycloneDDS peer discovery in the next step. -### New Docker YAML Configuration Setting +## Update Docker and DDS configuration Before you begin, ensure that Docker is installed on both of your development instances. Review the [Docker install guide](/install-guides/docker/docker-engine/) if needed. First, clone the demo repo and create xml file called `cycloneDDS.xml` -#### Step 1: Clone the repository and prepare configuration files +## Clone the repository and prepare configuration files ```bash git clone https://github.com/odincodeshen/openadkit_demo.autoware.git @@ -104,7 +104,7 @@ This command will download all images defined in the docker-compose-2ins.yml fil - odinlmshen/autoware-planning-control:v1.0 - odinlmshen/autoware-visualizer:v1.0 -#### Step 2: Configure CycloneDDS for Peer-to-Peer Communication +## Configure CycloneDDS for peer-to-peer communication The cycloneDDS.xml file is used to customize how CycloneDDS (the middleware used by ROS 2) discovers and communicates between distributed nodes. @@ -146,12 +146,12 @@ Please copy the following configuration into docker/cycloneDDS.xml on both machi 3. You can find the more detail about CycloneDDS setting [Configuration](https://cyclonedds.io/docs/cyclonedds/latest/config/config_file_reference.html#cyclonedds-domain-internal-socketreceivebuffersize) {{% /notice %}} -#### Step 3: Update the Docker Compose Configuration for Multi-Host Deployment +## Update the Docker Compose Configuration for Multi-Host Deployment To support running containers across two separate hosts, you’ll need to modify the docker/docker-compose-2ins.yml file. This includes removing inter-container dependencies and updating the network and environment configuration. -##### Remove Cross-Container Dependency +## Remove cross-container dependency Since the planning-control and simulator containers will now run on different machines, you must remove any depends_on references between them to prevent Docker from attempting to start them on the same host. @@ -258,7 +258,7 @@ services: Before moving to the next step, make sure that `docker-compose-2ins.yml` and `cycloneDDS.xml` are already present on both instances. -#### Step 4: Optimize Network Settings for DDS Communication +## Optimize Network Settings for DDS Communication In a distributed DDS setup, `high-frequency UDP traffic` between nodes may lead to `IP packet fragmentation` or `buffer overflows`, especially under load. These issues can degrade performance or cause unexpected system behavior. @@ -295,7 +295,7 @@ Links to documentation: - [ROS2 documentation](https://docs.ros.org/en/humble/How-To-Guides/DDS-tuning.html#cyclone-dds-tuning) -#### Step 5: Verifying Cross-Instance DDS Communication with ROS 2 +## Verify DDS communication between instances using ROS 2 To confirm that ROS 2 nodes can exchange messages across two separate EC2 instances using DDS, this test will walk you through a minimal publisher–subscriber setup using a custom topic. From e11cd13b24baa4195f5429ff785e47c0e07492b4 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 09:29:00 +0000 Subject: [PATCH 11/21] Updates --- .../2_data_distribution_service.md | 2 +- .../4_multiinstance_executing.md | 20 +++++++++---------- .../openadkit2_safetyisolation/_index.md | 2 +- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md index 0f1b7145b7..dbef040958 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md @@ -17,7 +17,7 @@ In modern vehicles, multiple sensors such as LiDAR, radar, and cameras must cont DDS ensures these components share data seamlessly and in real time, both within the vehicle and across infrastructure such as V2X systems, including traffic lights and road sensors. {{% notice Tip %}} -To get started with open-source DDS on Arm platforms, check out the [Installation Guide for CycloneDDS](https://learn.arm.com/install-guides/cyclonedds) on how to install open-source DDS on an Arm platform. +To get started with open-source DDS on Arm platforms, see the [Installation Guide for CycloneDDS](https://learn.arm.com/install-guides/cyclonedds). {{% /notice %}} diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index 7bb1696fff..8e10a4292b 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -1,5 +1,5 @@ --- -title: Execute OpenAD Kit across distributed ROS 2 instances +title: Run OpenAD Kit across distributed ROS 2 instances weight: 9 @@ -7,17 +7,17 @@ weight: 9 layout: learningpathall --- -## What this distributed demo shows you +## What you'll learn in this section -In this section, you’ll bring all the previous setup together and execute the full OpenAD Kit demo across two Arm-based instances. +In this section, you'll run the full OpenAD Kit demo across two Arm-based cloud instances using the setup from previous steps. -OpenAD Kit is an open-source reference design for autonomous driving workloads on Arm. It demonstrates how Autoware modules can be deployed on scalable infrastructure, either on a single machine or distributed across multiple compute nodes. +The OpenAD Kit is an open-source reference design for autonomous driving workloads on Arm. It demonstrates how Autoware modules can run on scalable infrastructure, whether on a single machine or distributed across multiple compute nodes using ROS 2 and DDS. -## Prepare launch scripts on both instances +## Set up launch scripts on both instances -This setup separates the simulation/visualization environment from the planning-control logic, allowing you to explore how ROS 2 nodes communicate over a distributed system using DDS (Data Distribution Service). +This setup separates the simulation and visualization environment from the planning and control logic, allowing you to explore how ROS 2 nodes communicate over a distributed system using DDS (Data Distribution Service). -To start the system, you need to configure and run separate launch commands on each machine. +To start the system, run separate launch scripts on each machine. On each instance, copy the appropriate launch script into the `openadkit_demo.autoware/docker` directory. @@ -66,7 +66,7 @@ On each instance, copy the appropriate launch script into the `openadkit_demo.au {{< /tab >}} {{< /tabpane >}} -You can also find the prepared launch scripts `opad_planning.sh` and `opad_sim_vis.sh` inside the `openadkit_demo.autoware/docker` directory on both instances. +You can also find these scripts `opad_planning.sh` and `opad_sim_vis.sh` inside the `openadkit_demo.autoware/docker` directory on both instances. These scripts encapsulate the required environment variables and container commands for each role. @@ -89,9 +89,9 @@ Once both machines are running their respective launch scripts, the Visualizer w http://[Visualizer public IP address]:6080/vnc.html -You can open this link in a browser to observe the demo behavior, which will closely resemble the output from the [previous learning path](http://learn.arm.com/learning-paths/automotive/openadkit1_container/4_run_openadkit/). +Open this link in your browser to watch the demo, which closely resembles the output in the [previous learning path](http://learn.arm.com/learning-paths/automotive/openadkit1_container/4_run_openadkit/). -![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS](split_aws_run.gif "Figure 4: Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") +![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS alt-text#center](split_aws_run.gif "Figure 4: Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") You’ve now run the OpenAD Kit across two nodes with separated control and visualization roles. DDS enabled real-time, peer-to-peer communication between the ROS 2 nodes, supporting synchronized behavior across the planning and simulation components deployed on two separate instances. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md index 8d265bafe6..55245d22ff 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/_index.md @@ -3,7 +3,7 @@ title: Prototype safety-critical isolation for autonomous driving systems on Neo minutes_to_complete: 60 -who_is_this_for: This Learning Path is for experienced automotive engineers developing safety-critical systems. You'll learn how to accelerate ISO 26262-compliant development workflows using Arm-based cloud compute, containerized simulation, and DDS-based communication. +who_is_this_for: This Learning Path is for automotive engineers developing safety-critical systems. You'll learn how to accelerate ISO 26262-compliant development workflows using Arm-based cloud compute, containerized simulation, and DDS-based communication. learning_objectives: - Apply functional safety principles, including risk prevention, fault detection, and ASIL compliance, to build robust, certifiable automotive systems From 1b982d676d4f759ccc5dc16e7dd855b4aa9746a9 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 10:36:40 +0000 Subject: [PATCH 12/21] Updates --- .../1d_safety_island_arch.md | 2 +- .../2_data_distribution_service.md | 2 +- .../3_container_spliting.md | 21 ++++++++++++------- 3 files changed, 15 insertions(+), 10 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index 5f3be175ab..a6aa9347b4 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -36,7 +36,7 @@ Safety islands are often implemented as lockstep cores or separate MCUs that run - Autonomous Vehicles → safe stopping (fail-safe mode) - Industrial Equipment → emergency power cutoff or speed reduction -## Why safety island matters for functional safety +## Why a safety island matters for functional safety A safety island helps systems respond to high-risk scenarios and reduces the likelihood of catastrophic failures. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md index dbef040958..eabd2f6d9b 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/2_data_distribution_service.md @@ -77,7 +77,7 @@ DDS supports multiple transport mechanisms to optimize communication efficiency: The following table highlights how DDS improves upon traditional client-server communication patterns in the context of real-time automotive applications: -| Feature | Traditional Client-Server Architecture | DDS Publish-Subscribe Model | +| Feature | Traditional client-server architecture | DDS publish-subscribe model | |----------------------|--------------------------------------------|--------------------------- | | Data Transmission | Relies on a central server | Direct peer-to-peer communication | | Latency | Higher latency | Low latency | diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md index 1620062325..6710ace5e9 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md @@ -8,12 +8,12 @@ layout: learningpathall ## Refactor OpenAD Kit for distributed deployment -Now that you’ve explored the concept of a Safety Island, a dedicated subsystem responsible for executing safety-critical control logic, and learned how DDS (Data Distribution Service) enables real-time, distributed communication, you’ll refactor the original OpenAD Kit architecture into a multi-instance deployment. +Now that you’ve explored the concept of a safety island, a dedicated subsystem responsible for executing safety-critical control logic, and learned how DDS (Data Distribution Service) enables real-time, distributed communication, you’ll refactor the original OpenAD Kit architecture into a multi-instance deployment. In [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](http://learn.arm.com/learning-paths/automotive/openadkit1_container/), you deployed three container components on a single Arm-based instance, handling: - Simulation environment - Visualization -- Planning-Control +- Planning and control In this session, you will split the simulation and visualization stack from the planning-control logic and deploy them across two independent Arm-based instances. @@ -141,9 +141,9 @@ Please copy the following configuration into docker/cycloneDDS.xml on both machi ``` {{% notice Note %}} -1. Make sure the network interface name (ens5) matches the one on your EC2 instances. You can verify this using `ip -br a`. -2. This configuration disables multicast and enables static peer discovery between the two machines using unicast. -3. You can find the more detail about CycloneDDS setting [Configuration](https://cyclonedds.io/docs/cyclonedds/latest/config/config_file_reference.html#cyclonedds-domain-internal-socketreceivebuffersize) +- Make sure the network interface name (for example, `ens5`) matches the one used by your EC2 instances. You can verify the instance name by running `ip -br a`. +- This configuration disables multicast and enables static peer discovery between the two machines using unicast. +- For more information on CycloneDDS settings, see the [Cyclone DDS Configuration Guide](https://cyclonedds.io/docs/cyclonedds/latest/config/config_file_reference.html#cyclonedds-domain-internal-socketreceivebuffersize). {{% /notice %}} ## Update the Docker Compose Configuration for Multi-Host Deployment @@ -162,7 +162,7 @@ Since the planning-control and simulator containers will now run on different ma # - simulator ``` -##### Enable Host Networking +## Enable host networking All three containers (visualizer, simulator, planning-control) need access to the host’s network interfaces for DDS-based peer discovery. Replace Docker's default bridge network with host networking: @@ -172,7 +172,7 @@ Replace Docker's default bridge network with host networking: network_mode: host ``` -##### Use CycloneDDS Configuration via Environment Variable +## Apply the CycloneDDS configuration using an environment variable To ensure that each container uses your custom DDS configuration, mount the current working directory and set the CYCLONEDDS_URI environment variable: @@ -299,7 +299,7 @@ Links to documentation: To confirm that ROS 2 nodes can exchange messages across two separate EC2 instances using DDS, this test will walk you through a minimal publisher–subscriber setup using a custom topic. -##### On Planning-Control Node (Publisher) +## On the Planning-Control Node (Publisher) On the first EC2 instance, you will publish a custom message to the /hello topic using ROS 2. This will simulate outbound DDS traffic from the planning-control container. @@ -363,6 +363,11 @@ ros2 topic echo /hello ``` In the simulator container, you should see repeated outputs like: + +{{% notice tip %}} +If the subscriber shows a continuous stream of `/hello` messages, DDS discovery and ROS 2 communication between nodes are working as expected. +{{% /notice %}} + ``` root@ip-172-31-19-5:/autoware# ros2 topic echo /hello data: Hello From Planning From 6d307ca06e9854b41e2d948f7c425115fda1e815 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 12:37:42 +0000 Subject: [PATCH 13/21] Updates --- .../openadkit2_safetyisolation/1c_ISO26262.md | 4 +- .../1d_safety_island_arch.md | 18 +++--- .../1e_implement functional_safety.md | 24 ++++---- .../3_container_spliting.md | 55 +++++++++---------- .../4_multiinstance_executing.md | 13 +++-- 5 files changed, 55 insertions(+), 59 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md index 57d48a7d74..511c708777 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md @@ -21,7 +21,7 @@ The V-model is a development framework where each design phase is paired with a {{% notice Note %}}In practice, many OEMs default to ASIL D for systems with any potential for passenger harm, even if the statistical likelihood of failure is low.{{% /notice %}} -## Apply ISO 26262 in real-world systems +## Apply ISO 26262 to real-world systems ISO 26262 applies to many safety-critical vehicle systems: @@ -31,7 +31,7 @@ ISO 26262 applies to many safety-critical vehicle systems: - **Battery management systems (BMS)** protect electric vehicle batteries from overheating, overcharging, or deep discharge. Built-in safety functions monitor temperature, balance voltage, and isolate faulty circuits to prevent thermal runaway. -These systems require dedicated hardware and software architectures that enforce functional safety guarantees. One common solution is the **Safety Island**, which is an isolated compute domain used to run safety-critical control logic independently from the main system. +These systems require dedicated hardware and software architectures that enforce functional safety guarantees. One common solution is the *safety island*, which is an isolated compute domain used to run safety-critical control logic independently from the main system. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md index a6aa9347b4..5f2f5798d6 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1d_safety_island_arch.md @@ -5,11 +5,9 @@ weight: 5 ### FIXED, DO NOT MODIFY layout: learningpathall --- -## How safety islands support functional safety in software systems +## How safety islands support functional safety -In automotive systems, a non-safety ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation. - -A safety island, by contrast, is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. +In automotive systems, a non-safety ECU (Electronic Control Unit) typically runs non-critical tasks such as infotainment or navigation. A safety island, by contrast, is dedicated to executing safety-critical control logic (for example, braking and steering) with strong isolation, redundancy, and determinism. The table below compares the characteristics of an ECU and a safety island in terms of their role in supporting functional safety. @@ -38,16 +36,16 @@ Safety islands are often implemented as lockstep cores or separate MCUs that run ## Why a safety island matters for functional safety -A safety island helps systems respond to high-risk scenarios and reduces the likelihood of catastrophic failures. +A safety island provides a dedicated environment for executing critical safety functions. Its key characteristics include: -- **Acts as an independent redundant safety layer** +- **Acting as an independent redundant safety layer** - Operates safety logic independently of the main processor -- **Supports ASIL-D safety level** +- **Supporting the ASIL-D safety level** - Enables the system to meet the highest ISO 26262 requirements for critical operations -- **Provides independent fault detection and recovery mechanisms** - - *Fail-safe*: activates a minimal-risk mode, such as limiting vehicle speed or switching to manual control - - *Fail-operational*: allows high-integrity systems, such as those in aerospace or autonomous driving, to continue functioning under fault conditions +- **Providing independent fault detection and recovery mechanisms:** + - *Fail-safe*: activating a minimal-risk mode, such as limiting vehicle speed or switching to manual control + - *Fail-operational*: allowing high-integrity systems, such as those in aerospace or autonomous driving, to continue functioning under fault conditions Safety islands play a key role in enabling ISO 26262 compliance by isolating safety-critical logic from general-purpose processing. They're a proven solution for improving system determinism, fault tolerance, and fallback behavior. \ No newline at end of file diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md index 60b53a465b..a83767f462 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md @@ -8,27 +8,27 @@ layout: learningpathall ## The software development lifecycle -Functional Safety affects both hardware and software development, particularly in areas such as requirement changes, version control, and test validation. For example, in ASIL-D level applications, every code change must go through a full impact analysis and regression testing to ensure it doesn't introduce new risks. +Functional safety affects both hardware and software development, particularly in areas such as requirement changes, version control, and test validation. For example, in ASIL-D level applications, every code change must go through a full impact analysis and regression testing to ensure it doesn't introduce new risks. ## Software development practices for functional safety These practices ensure that software meets industry standards and can withstand system-level failures: -- **Define requirements clearly** - - Specify safety-critical requirements and conduct formal risk assessments. +- **Defining requirements clearly** + - Specifying safety-critical requirements and conduct formal risk assessments. -- **Follow safety-oriented programming standards** - - Use MISRA C or CERT C/C++ and static analysis tools to detect unsafe behavior. +- **Following safety-oriented programming standards** + - Using MISRA C or CERT C/C++ and static analysis tools to detect unsafe behavior. -- **Implement fault-handling mechanisms** - - Use redundancy, health monitoring, and fail-safe logic to manage faults gracefully. +- **Implementing fault-handling mechanisms** + - Using redundancy, health monitoring, and fail-safe logic to manage faults gracefully. -- **Test and verify rigorously** - - Use Hardware-in-the-Loop (HIL) testing to validate behavior under realistic conditions. +- **Testing and verifying rigorously** + - Using Hardware-in-the-Loop (HIL) testing to validate behavior under realistic conditions. -- **Track changes with version control and audits** - - Use tools like Git, JIRA, or Polarion to manage revisions and maintain traceability for audits. +- **Tracking changes with version control and audits** + - Using tools like Git, JIRA, or Polarion to manage revisions and maintain traceability for audits. -Building an ASIL-partitioned development environment and adopting SOAFEE technologies can help improve software maintainability and ensure consistent compliance with functional safety standards. +- **Building an ASIL-partitioned development environment and adopting SOAFEE technologies** to help improve software maintainability and ensure consistent compliance with functional safety standards. {{% notice Note %}} This Learning Path builds on [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](/learning-paths/automotive/openadkit1_container/). It introduces functional safety practices from the earliest stages of software development. diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md index 6710ace5e9..6c5809f0cd 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md @@ -10,12 +10,12 @@ layout: learningpathall Now that you’ve explored the concept of a safety island, a dedicated subsystem responsible for executing safety-critical control logic, and learned how DDS (Data Distribution Service) enables real-time, distributed communication, you’ll refactor the original OpenAD Kit architecture into a multi-instance deployment. -In [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](http://learn.arm.com/learning-paths/automotive/openadkit1_container/), you deployed three container components on a single Arm-based instance, handling: -- Simulation environment +The predecessor Learning Path, [Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](http://learn.arm.com/learning-paths/automotive/openadkit1_container/), showed how to deploying three container components on a single Arm-based instance, to handle: +- The simulation environment - Visualization - Planning and control -In this session, you will split the simulation and visualization stack from the planning-control logic and deploy them across two independent Arm-based instances. +In this Learning Path, you will split the simulation and visualization stack from the planning-control logic and deploy them across two independent Arm-based instances. These nodes communicate using ROS 2 with DDS as the middleware layer, ensuring low-latency and fault-tolerant data exchange between components. @@ -23,23 +23,19 @@ These nodes communicate using ROS 2 with DDS as the middleware layer, ensuring l This architecture brings several practical benefits: -- Enhanced System Stability: -Decoupling components prevents resource contention and ensures that safety-critical functions remain deterministic and responsive. +- **Enhanced System Stability**: decoupling components prevents resource contention and ensures that safety-critical functions remain deterministic and responsive. -- Real-Time, Scalable Communication: -DDS enables built-in peer discovery and configurable QoS, removing the need for a central broker or manual network setup. +- **Real-Time, Scalable Communication**: DDS enables built-in peer discovery and configurable QoS, removing the need for a central broker or manual network setup. -- Improved Scalability and Performance Tuning: -Each instance can be tuned based on its workload—for example, simulation tasks can use GPU-heavy hardware, while planning logic may benefit from CPU-optimized setups. +- **Improved Scalability and Performance Tuning**: each instance can be tuned based on its workload,for example, simulation tasks can use GPU-heavy hardware, while planning logic might benefit from CPU-optimized setups. -- Support for Modular CI/CD Workflows: -With containerized separation, you can build, test, and deploy each module independently—enabling agile development and faster iteration cycles. +- **Support for Modular CI/CD Workflows**: with containerized separation, you can build, test, and deploy each module independently, which enables agile development and faster iteration cycles. -![img1 alt-text#center](aws_example.jpg "Figure 1: Split instance example in AWS") +![img1 alt-text#center](aws_example.jpg "Split instance example in AWS") ## Configure networking for DDS communication -To begin, launch two Arm-based VM instances. AWS EC2 is used, but you can use any Arm instances. +To begin, launch two Arm-based VM instances. AWS EC2 is used, but you can use any Arm-based instances. These instances will independently host your simulation and control workloads. @@ -66,7 +62,7 @@ Once both systems are operational, record the private IP addresses of each insta ## Update Docker and DDS configuration -Before you begin, ensure that Docker is installed on both of your development instances. Review the [Docker install guide](/install-guides/docker/docker-engine/) if needed. +Before you begin, ensure that Docker is installed on both of your development instances. Review the [Docker Install Guide](/install-guides/docker/docker-engine/) if needed. First, clone the demo repo and create xml file called `cycloneDDS.xml` @@ -95,11 +91,11 @@ export COMMON_FILE=/home/ubuntu/openadkit_demo.autoware/docker/etc/simulation/co docker compose -f docker-compose.yml pull ``` -{{% notice info %}} -Each image is around 4–6 GB, so pulling them may vary depending on your network speed. +{{% notice Note %}} +Each image is around 4–6 GB, so the time to download them can vary depending on your network speed. {{% /notice %}} -This command will download all images defined in the docker-compose-2ins.yml file, including: +This command downloads all images defined in the docker-compose-2ins.yml file, including: - odinlmshen/autoware-simulator:v1.0 - odinlmshen/autoware-planning-control:v1.0 - odinlmshen/autoware-visualizer:v1.0 @@ -108,7 +104,7 @@ This command will download all images defined in the docker-compose-2ins.yml fil The cycloneDDS.xml file is used to customize how CycloneDDS (the middleware used by ROS 2) discovers and communicates between distributed nodes. -Please copy the following configuration into docker/cycloneDDS.xml on both machines, and replace the IP addresses with the private IPs of each EC2 instance. +Copy the following configuration into docker/cycloneDDS.xml on both machines, and replace the IP addresses with the private IPs of each EC2 instance: ```xml @@ -153,7 +149,7 @@ This includes removing inter-container dependencies and updating the network and ## Remove cross-container dependency -Since the planning-control and simulator containers will now run on different machines, you must remove any depends_on references between them to prevent Docker from attempting to start them on the same host. +Since the planning-control and simulator containers will run on separate machines, remove any `depends_on` references between them. This prevents Docker from treating them as interdependent services on a single host. ```YAML planning-control: @@ -164,7 +160,8 @@ Since the planning-control and simulator containers will now run on different ma ## Enable host networking -All three containers (visualizer, simulator, planning-control) need access to the host’s network interfaces for DDS-based peer discovery. +All three containers (visualizer, simulator, and planning-control) need access to the host’s network interfaces for DDS-based peer discovery. + Replace Docker's default bridge network with host networking: ```YAML @@ -270,10 +267,10 @@ sudo sysctl net.ipv4.ipfrag_high_thresh=134217728 sudo sysctl -w net.core.rmem_max=2147483647 ``` -Explanation of Parameters -- `net.ipv4.ipfrag_time=3`: Reduces the timeout for holding incomplete IP fragments, helping free up memory more quickly. -- `net.ipv4.ipfrag_high_thresh=134217728`: Increases the memory threshold for IP fragment buffers to 128 MB, preventing early drops under high load. -- `net.core.rmem_max=2147483647`: Expands the maximum socket receive buffer size to support high-throughput DDS traffic. +## Explanation of parameters +- `net.ipv4.ipfrag_time=3`: reduces the timeout for holding incomplete IP fragments, helping free up memory more quickly. +- `net.ipv4.ipfrag_high_thresh=134217728`: increases the memory threshold for IP fragment buffers to 128 MB, preventing early drops under high load. +- `net.core.rmem_max=2147483647`: expands the maximum socket receive buffer size to support high-throughput DDS traffic. To ensure these settings persist after reboot, create a configuration file under /etc/sysctl.d/: @@ -297,14 +294,14 @@ Links to documentation: ## Verify DDS communication between instances using ROS 2 -To confirm that ROS 2 nodes can exchange messages across two separate EC2 instances using DDS, this test will walk you through a minimal publisher–subscriber setup using a custom topic. +To confirm that ROS 2 nodes can exchange messages across two separate EC2 instances using DDS, this test walks you through a minimal publisher-subscriber setup using a custom topic. -## On the Planning-Control Node (Publisher) +## On the planning-control node (publisher) On the first EC2 instance, you will publish a custom message to the /hello topic using ROS 2. This will simulate outbound DDS traffic from the planning-control container. -Set the required environment variables and launch the planning-control container. +Set the required environment variables and launch the planning-control container: ```bash export SCRIPT_DIR=/home/ubuntu/openadkit_demo.autoware/docker @@ -326,7 +323,7 @@ ros2 topic list ros2 topic pub /hello std_msgs/String "data: Hello From Planning" --rate 1 ``` -##### On Simulator Node (Subscriber) side +## On the simulator node (subscriber) On the second EC2 instance, you will listen for the /hello topic using ros2 topic echo. This confirms that DDS communication from the planning node is received on the simulation node. @@ -365,7 +362,7 @@ ros2 topic echo /hello In the simulator container, you should see repeated outputs like: {{% notice tip %}} -If the subscriber shows a continuous stream of `/hello` messages, DDS discovery and ROS 2 communication between nodes are working as expected. +If the subscriber shows a continuous stream of `/hello` messages, DDS discovery and ROS 2 communication between the nodes is working as expected. {{% /notice %}} ``` diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index 8e10a4292b..e9a5b691db 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -9,15 +9,15 @@ layout: learningpathall ## What you'll learn in this section -In this section, you'll run the full OpenAD Kit demo across two Arm-based cloud instances using the setup from previous steps. - The OpenAD Kit is an open-source reference design for autonomous driving workloads on Arm. It demonstrates how Autoware modules can run on scalable infrastructure, whether on a single machine or distributed across multiple compute nodes using ROS 2 and DDS. +In this section, you'll run the full OpenAD Kit demo across two Arm-based cloud instances using the setup from previous steps. + ## Set up launch scripts on both instances This setup separates the simulation and visualization environment from the planning and control logic, allowing you to explore how ROS 2 nodes communicate over a distributed system using DDS (Data Distribution Service). -To start the system, run separate launch scripts on each machine. +To start the system, run separate launch scripts on each machine: On each instance, copy the appropriate launch script into the `openadkit_demo.autoware/docker` directory. @@ -84,14 +84,15 @@ On the Simulation and Visualization node, execute: ./opad_sim_vis.sh ``` +Once both machines are running their launch scripts, the Visualizer container exposes a web-accessible interface at: +http://[Visualizer public IP address]:6080/vnc.html -Once both machines are running their respective launch scripts, the Visualizer will generate a web-accessible interface on: +Open this link in your browser to observe the simulation in real time. -http://[Visualizer public IP address]:6080/vnc.html Open this link in your browser to watch the demo, which closely resembles the output in the [previous learning path](http://learn.arm.com/learning-paths/automotive/openadkit1_container/4_run_openadkit/). -![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS alt-text#center](split_aws_run.gif "Figure 4: Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") +![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS alt-text#center](split_aws_run.gif "Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") You’ve now run the OpenAD Kit across two nodes with separated control and visualization roles. DDS enabled real-time, peer-to-peer communication between the ROS 2 nodes, supporting synchronized behavior across the planning and simulation components deployed on two separate instances. From 76df0f324a1216dd88f1a28ce37d6371a87cc1c5 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 12:46:37 +0000 Subject: [PATCH 14/21] Final --- .../4_multiinstance_executing.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md index e9a5b691db..142aa3e88f 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/4_multiinstance_executing.md @@ -84,13 +84,9 @@ On the Simulation and Visualization node, execute: ./opad_sim_vis.sh ``` -Once both machines are running their launch scripts, the Visualizer container exposes a web-accessible interface at: -http://[Visualizer public IP address]:6080/vnc.html +Once both machines are running their launch scripts, the Visualizer container exposes a web-accessible interface at: http://6080/vnc.html. -Open this link in your browser to observe the simulation in real time. - - -Open this link in your browser to watch the demo, which closely resembles the output in the [previous learning path](http://learn.arm.com/learning-paths/automotive/openadkit1_container/4_run_openadkit/). +Open this link in your browser to observe the simulation in real time. The demo closely resembles the output in the [previous Learning Path, Deploy Open AD Kit containerized autonomous driving simulation on Arm Neoverse](http://learn.arm.com/learning-paths/automotive/openadkit1_container/4_run_openadkit/). ![Distributed OpenAD Kit simulation running on two Arm-based instances with visualizer and simulator coordination over DDS alt-text#center](split_aws_run.gif "Visualizer output from a distributed OpenAD Kit simulation showing ROS 2 modules running across two cloud instances using DDS communication.") From 06456d25c0803410e88d8718b8a01bdfd7acfd65 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 12:50:51 +0000 Subject: [PATCH 15/21] removed clutter --- tools/enhanced_style_check.py | 430 --------------------------------- tools/stats_data_generate.py | 432 ---------------------------------- 2 files changed, 862 deletions(-) delete mode 100644 tools/enhanced_style_check.py delete mode 100644 tools/stats_data_generate.py diff --git a/tools/enhanced_style_check.py b/tools/enhanced_style_check.py deleted file mode 100644 index 93de0209af..0000000000 --- a/tools/enhanced_style_check.py +++ /dev/null @@ -1,430 +0,0 @@ - -def extract_sentences_with_matches(text, pattern): - import re - sentences = re.split(r'(?<=[.!?])\s+', text) - matches = [] - for sentence in sentences: - if re.search(pattern, sentence): - matches.append(sentence.strip()) - return matches - -def apply_manual_review_rules(text, rules): - suggestions = [] - for rule in rules: - pattern = re.compile(rule["pattern"]) - matches = pattern.finditer(text) - for match in matches: - sentence = extract_sentences_with_matches(text, rule["pattern"]) - suggestions.append({ - "match": match.group(), - "replacement": rule["replacement"], - "reason": rule["reason"], - "sentence": sentence - }) - return suggestions - - -#!/usr/bin/env python3 -""" -Enhanced style checker for Arm Learning Paths content. -This script checks markdown files against writing style guidelines from a JSON file -and uses spaCy for passive voice detection. -""" - -import argparse -import json -import os -import re -import sys -from pathlib import Path - -# Import spaCy if available -try: - import spacy - SPACY_AVAILABLE = True - # Try to load the English model - try: - nlp = spacy.load("en_core_web_sm") - except: - print("Warning: spaCy model 'en_core_web_sm' not found. Will try to download it.") - try: - from spacy.cli import download - download("en_core_web_sm") - nlp = spacy.load("en_core_web_sm") - print("Successfully downloaded and loaded spaCy model.") - except: - print("Error: Could not download spaCy model. Passive voice detection will be limited.") - SPACY_AVAILABLE = False -except ImportError: - print("Warning: spaCy not installed. Using basic passive voice detection.") - SPACY_AVAILABLE = False - -def load_style_rules(rules_file): - """Load style rules from a JSON file.""" - try: - with open(rules_file, "r", encoding="utf-8") as f: - return json.load(f) - except Exception as e: - print(f"Error loading style rules: {e}") - return [] - -def is_in_code_block(lines, line_index): - """Check if the line is within a code block.""" - code_block_count = 0 - for i in range(line_index): - if re.match(r'^```', lines[i]): - code_block_count += 1 - - return code_block_count % 2 == 1 # Odd count means inside a code block - -def is_in_yaml_frontmatter(lines, line_index): - """Check if the line is within YAML frontmatter.""" - if line_index == 0 and lines[0].strip() == '---': - return True - - frontmatter_markers = 0 - for i in range(line_index): - if lines[i].strip() == '---': - frontmatter_markers += 1 - - # If we've seen an odd number of markers, we're in frontmatter - return frontmatter_markers % 2 == 1 - -def capitalize_if_at_start(original, replacement, match): - """Capitalize the replacement if it's at the start of a sentence.""" - # Check if the match is at the start of the string or after a period and space - start_of_sentence = match.start() == 0 or (match.start() > 1 and original[match.start()-2:match.start()] == '. ') - - if start_of_sentence and replacement and replacement[0].islower(): - return replacement[0].upper() + replacement[1:] - return replacement - -def detect_passive_voice_with_spacy(text): - """ - Detect passive voice using spaCy's dependency parsing. - Returns a list of (passive_text, suggested_active) tuples. - """ - if not SPACY_AVAILABLE: - return [] - - doc = nlp(text) - passive_constructions = [] - - for token in doc: - # Look for passive auxiliary verbs - if token.dep_ == "auxpass": - # Find the main verb - verb = token.head - - # Find the subject (usually nsubjpass) - subject = None - for child in verb.children: - if child.dep_ == "nsubjpass": - subject = child - break - - # Find the agent (usually introduced by "by") - agent = None - for child in verb.children: - if child.dep_ == "agent": - for agent_child in child.children: - if agent_child.dep_ == "pobj": - agent = agent_child - break - break - - # If we have both subject and agent, we can suggest an active voice alternative - if subject and agent: - # Extract the spans of text - passive_span = doc[max(0, subject.i - 1):min(len(doc), verb.i + 2)] - if agent.i > verb.i: - passive_span = doc[max(0, subject.i - 1):min(len(doc), agent.i + 1)] - - # Create active voice suggestion - active_suggestion = f"{agent.text} {verb.lemma_} {subject.text}" - - # Capitalize if at start of sentence - if passive_span.start == 0 or (passive_span.start > 1 and doc[passive_span.start-2].text == '.'): - active_suggestion = active_suggestion[0].upper() + active_suggestion[1:] - - passive_constructions.append((passive_span.text, active_suggestion)) - - return passive_constructions - -def fix_passive_voice(line): - """ - Fix passive voice constructions by swapping subject and object. - This is a more sophisticated approach than simple pattern replacement. - """ - # Common passive voice patterns with specific replacements - passive_patterns = [ - (r'The data is processed by the system', r'The system processes the data'), - (r'The code is handled by the compiler', r'The compiler handles the code'), - (r'The configuration was managed by the user', r'The user managed the configuration'), - (r'The documentation was created by the team', r'The team created the documentation'), - (r'The results are generated by the algorithm', r'The algorithm generates the results'), - (r'The API is provided by the service', r'The service provides the API') - ] - - # Try each specific pattern first - for pattern, replacement in passive_patterns: - if re.search(pattern, line, re.IGNORECASE): - return re.sub(pattern, replacement, line, flags=re.IGNORECASE) - - # Generic patterns as fallback - generic_patterns = [ - # Present tense passive - (r'(\w+) is (\w+ed) by (\w+)', r'\3 \2s \1'), - (r'(\w+) are (\w+ed) by (\w+)', r'\3 \2 \1'), - # Past tense passive - (r'(\w+) was (\w+ed) by (\w+)', r'\3 \2 \1'), - (r'(\w+) were (\w+ed) by (\w+)', r'\3 \2 \1') - ] - - for pattern, replacement in generic_patterns: - if re.search(pattern, line): - return re.sub(pattern, replacement, line) - - return line - -def check_style(content, file_path, style_rules): - """Check content against style rules and return suggestions.""" - suggestions = [] - lines = content.split("\n") - - # First, check for passive voice using spaCy if available - if SPACY_AVAILABLE: - # Process each paragraph separately to maintain context - paragraphs = [] - current_paragraph = [] - - for i, line in enumerate(lines): - # Skip code blocks, YAML frontmatter, headings, and links - if (is_in_code_block(lines, i) or - is_in_yaml_frontmatter(lines, i) or - re.match(r'^#+\s', line) or - re.search(r'^\s*\[.*\]:\s*', line)): - # End the current paragraph if any - if current_paragraph: - paragraphs.append((current_paragraph[0], " ".join(current_paragraph[1]))) - current_paragraph = [] - continue - - # Skip empty lines - they end paragraphs - if not line.strip(): - if current_paragraph: - paragraphs.append((current_paragraph[0], " ".join(current_paragraph[1]))) - current_paragraph = [] - continue - - # Add line to current paragraph - if not current_paragraph: - current_paragraph = [i, [line]] - else: - current_paragraph[1].append(line) - - # Add the last paragraph if any - if current_paragraph: - paragraphs.append((current_paragraph[0], " ".join(current_paragraph[1]))) - - # Check each paragraph for passive voice - for start_line, paragraph_text in paragraphs: - passive_constructions = detect_passive_voice_with_spacy(paragraph_text) - - for passive_text, active_suggestion in passive_constructions: - # Find which line contains this passive construction - line_offset = 0 - for j, line in enumerate(lines[start_line:start_line + 10]): # Look at next 10 lines max - if passive_text in line: - line_index = start_line + j - suggestions.append({ - "file": file_path, - "line": line_index + 1, # 1-based line numbers - "original": line, - "suggested": line.replace(passive_text, active_suggestion), - "reason": "Convert passive voice to active voice for clarity and directness (detected by spaCy)." - }) - break - - # Then check each line against style rules - for i, line in enumerate(lines): - # Skip code blocks and YAML frontmatter - if is_in_code_block(lines, i) or is_in_yaml_frontmatter(lines, i): - continue - - # Skip headings (lines starting with #) - if re.match(r'^#+\s', line): - continue - - # Skip links and image references - if re.search(r'^\s*\[.*\]:\s*', line): - continue - - # Check for passive voice using regex (as fallback) - if not SPACY_AVAILABLE: - passive_patterns = [ - r'\b(?:is|are|was|were)\s+\w+ed\s+by\b', - r'\b(?:is|are|was|were)\s+(?:handled|managed|created|generated|provided)\s+by\b' - ] - - for pattern in passive_patterns: - if re.search(pattern, line, re.IGNORECASE): - # Try to fix passive voice - fixed_line = fix_passive_voice(line) - if fixed_line != line: - suggestions.append({ - "file": file_path, - "line": i + 1, - "original": line, - "suggested": fixed_line, - "reason": "Convert passive voice to active voice for clarity and directness." - }) - # Only one suggestion per line to avoid conflicts - break - - # If we already have a suggestion for this line, skip further checks - if any(sugg["line"] == i + 1 for sugg in suggestions): - continue - - # Check against other style rules - for rule in style_rules: - matches = list(re.finditer(rule["pattern"], line, re.IGNORECASE)) - for match in matches: - # Create a suggestion - original = line - - # Get the matched text - matched_text = match.group(0) - - # Determine if replacement should be capitalized - replacement = rule["replacement"] - if match.start() == 0 or (match.start() >= 2 and line[match.start()-2:match.start()] == '. '): - if replacement and replacement[0].islower(): - replacement = replacement[0].upper() + replacement[1:] - - # Apply the replacement - suggested = line[:match.start()] + replacement + line[match.end():] - - if original != suggested: - suggestions.append({ - "file": file_path, - "line": i + 1, - "original": original, - "suggested": suggested, - "reason": rule["reason"], - }) - # Only one suggestion per line to avoid conflicts - break - - return suggestions - -def save_suggestions_to_file(suggestions, output_file="style_suggestions.json"): - """Save suggestions to a JSON file.""" - with open(output_file, "w") as f: - json.dump(suggestions, f, indent=2) - print(f"Saved suggestions to {output_file}") - -def print_suggestions(suggestions): - """Print suggestions in a readable format.""" - if not suggestions: - print("No style issues found.") - return - - print(f"\nFound {len(suggestions)} style issues:") - print("=" * 80) - - for i, sugg in enumerate(suggestions, 1): - print(f"Issue {i}:") - print(f"File: {sugg['file']}") - print(f"Line: {sugg['line']}") - print(f"Reason: {sugg['reason']}") - print(f"Original: {sugg['original']}") - print(f"Suggested: {sugg['suggested']}") - print("-" * 80) - -def main(): - parser = argparse.ArgumentParser(description="Check markdown files for style issues") - parser.add_argument("--file", help="Path to a specific markdown file to check") - parser.add_argument("--dir", help="Directory containing markdown files to check") - parser.add_argument("--rules", default="tools/style_rules.json", help="JSON file containing style rules") - parser.add_argument("--output", default="style_suggestions.json", help="Output file for suggestions") - parser.add_argument("--install-spacy", action="store_true", help="Install spaCy and download the English model") - args = parser.parse_args() - - # Install spaCy if requested - if args.install_spacy: - print("Installing spaCy and downloading the English model...") - import subprocess - subprocess.call([sys.executable, "-m", "pip", "install", "spacy"]) - subprocess.call([sys.executable, "-m", "spacy", "download", "en_core_web_sm"]) - print("Installation complete. Please run the script again without --install-spacy.") - sys.exit(0) - - if not args.file and not args.dir: - print("Error: Please provide either --file or --dir argument") - sys.exit(1) - - # Load style rules - style_rules = load_style_rules(args.rules) - if not style_rules: - print("Error: No style rules loaded. Check the rules file.") - sys.exit(1) - - print(f"Loaded {len(style_rules)} style rules from {args.rules}") - - all_suggestions = [] - - # Check a specific file - if args.file: - if not os.path.isfile(args.file): - print(f"Error: File not found: {args.file}") - sys.exit(1) - - if not args.file.endswith((".md", ".mdx")): - print(f"Warning: {args.file} is not a markdown file. Checking anyway.") - - with open(args.file, "r", encoding="utf-8") as f: - content = f.read() - - suggestions = check_style(content, args.file, style_rules) - all_suggestions.extend(suggestions) - print(f"Checked {args.file}: Found {len(suggestions)} style issues") - - # Check all markdown files in a directory - if args.dir: - if not os.path.isdir(args.dir): - print(f"Error: Directory not found: {args.dir}") - sys.exit(1) - - for root, _, files in os.walk(args.dir): - for file in files: - if file.endswith((".md", ".mdx")): - file_path = os.path.join(root, file) - with open(file_path, "r", encoding="utf-8") as f: - content = f.read() - - suggestions = check_style(content, file_path, style_rules) - all_suggestions.extend(suggestions) - print(f"Checked {file_path}: Found {len(suggestions)} style issues") - - # Print and save suggestions - print_suggestions(all_suggestions) - save_suggestions_to_file(all_suggestions, args.output) - -if __name__ == "__main__": - main() - - - -def run_manual_review_interactively(text, rules): - updated_text = text - manual_suggestions = apply_manual_review_rules(text, rules) - for suggestion in manual_suggestions: - for sentence in suggestion["sentence"]: - print(f"\nContext: {sentence}") - print(f"Suggestion: Replace '{suggestion['match']}' with '{suggestion['replacement']}'") - print(f"Reason: {suggestion['reason']}") - choice = input("Apply this change? (y/n): ").strip().lower() - if choice == 'y': - updated_text = updated_text.replace(suggestion["match"], suggestion["replacement"], 1) - return updated_text diff --git a/tools/stats_data_generate.py b/tools/stats_data_generate.py deleted file mode 100644 index cb1dd571c0..0000000000 --- a/tools/stats_data_generate.py +++ /dev/null @@ -1,432 +0,0 @@ -# Next steps: -# Add 'cross platform' into category checking and addition -# Record same for install guides -# Verify test data & totals matches reality -# -------- move on to individual_authors&contributors -# -------- move on to GitHub API - - - -''' -Goal: Every week, update the stats_data.yml file automatically by reading the current state and GitHub API - -Steps: - 1) Read in stats_data.yml as a python dict - 2) Verify we can read in new stats, via a function for each datapoint to log - 2a) Directory structure read - 2b) GitHub API obtain data - 3) If we have new data, append to stats_data.yml. If not, fail script to notify GitHub folks -''' - -''' -weekly_in_YYYY_MMM_DD: - 2023-Mar-03: # Date, updated weekly, in YYYY-MMM-DD format - content: # Dict of content related stats. Source: # of LP in each directory - total: 33 # raw sum of all all below - ucontroller: 5 - embedded: 2 - desktop: 1 - server: 10 - mobile: 3 - cross: 2 # Number of learning paths in cross-platform area; for awareness - install_guides: 10 - individual_authors: # Dict of author stats. Source: Crawl over each LP and IG, urlize author name, and add totals - jason_andrews: 24 - pareena_verma: 22 - ronan_synnott: 15 - florent_lebeau: 9 - jane_doe: 2 - john_smith: 2 - contributions: # Dict of contribution stats. Source: Cross-match found author names in LPs and IGs with 'contributors.csv' to identify them as internal (with company Arm) or external (all others) - internal: 70 - external: 4 - issues: # Dict of GitHub issues raised in this repo. Source: GitHub API - avg_close_time_hrs: 42 - percent_closed_vs_total: 90.5 - num_issues: 66 - github_engagement: # Dict of GitHub repo webpage engagement numbers. Source: GitHub API - num_prs: 34 - num_forks: 20 -''' - - -''' ---- -summary: # Basic summary of tests in this site. Source: adding numbers when iterating over sw_categories below - content_total: 30 - content_with_tests_enabled: 10 # Will match the number of learning paths - content_with_all_tests_passing: 9 - - -sw_categories: # Dict of content test status. Source: Iterate over each LP category and IGs _index.md files to scrape data and store in this one place. - server: - intrinsics: - title: Integrate Intrinsics here - tests_and_status: - - amd64/ubuntu:latest: passed - - arm64v8/ubuntu:latest: passed - avh_cicd: - title: AVH Title - tests_and_status: - - RPi3:latest: passed -''' - - - -import os -import sys -import csv -import yaml -import argparse -import requests -from pathlib import Path -from datetime import datetime - - -# Set paths -data_weekly_file_path = Path('../data/stats_weekly_data.yml') -tests_status_file_path = Path('../data/stats_current_test_info.yml') -learning_path_dir = Path('../content/learning-paths/') -install_guide_dir = Path('../content/install-guides/') -lp_and_ig_content_dirs = ['embedded-and-microcontrollers','iot','laptops-and-desktops','servers-and-cloud-computing','mobile-graphics-and-gaming','automotive','cross-platform','install-guides'] - - -# Obtain today's date in YYYY-MM-DD -date_today = datetime.now().strftime("%Y-%m-%d") - -# Set global vars for processing ease -new_weekly_entry = {} -new_tests_entry = {} - -############################################################################# -############################################################################# - - -def pretty(d, indent=0): - for key, value in d.items(): - print('\t' * indent + str(key)) - if isinstance(value, dict): - pretty(value, indent+1) - else: - print('\t' * (indent+1) + str(value)) - -def printInfo(week,test): - print('============================================================================') - print('New weekly entry dict appended:') - pretty(week) - print('============================================================================') - print('New test entry dict overwriting:') - pretty(test) - print('============================================================================') - - -def urlize(in_str): - # Replacate Hugo urlize function to make it easier to process strings for consistent analysis. - # ' ' -> '-' - # capitals -> lowercase - return in_str.replace(' ','-').lower() - -def mdToMetadata(md_file_path): - metadata_text = "" - content_text = "" - inMetadata = False - - # Remove last '---' to propery read in yaml metadata component of .md file - with open(md_file_path, encoding="utf8") as f: - for line in (f.readlines()): - if ('---' in line) and inMetadata: - break # go on when needed to gather content text - elif ('---' in line) and (not inMetadata): - inMetadata = True - metadata_text += line - - # Load yaml - metadata_dic = yaml.safe_load(metadata_text) - return metadata_dic - -def authorAdd(author_names,tracking_dic): - ### Update 'individual_authors' area, raw number by each author. - - # Support multiple authors by iterating through a list. - # First, check if author_name is a list or not. If not, make it a list - if not isinstance(author_names, list): - author_names = [author_names] - for author_name in author_names: - - # Check if author already exists as key. If not, add new key - author_urlized = urlize(author_name) - if author_urlized in tracking_dic['individual_authors']: - # Update number for this author - tracking_dic['individual_authors'][author_urlized] = tracking_dic['individual_authors'][author_urlized] + 1 - else: - # Add key to dic with 1 to their name - tracking_dic['individual_authors'][author_urlized] = 1 - - ### Update 'contributions' area, internal vs external contributions - - # open the contributors CSV file - with open('../assets/contributors.csv', mode ='r')as file: - csvFile = csv.reader(file) - for line in csvFile: - company = line[1] - # If author in the line, check if they work at Arm or not, and increment contributions number for internal or external - if author_name in line: - if company == 'Arm': - tracking_dic['contributions']['internal'] = tracking_dic['contributions']['internal'] + 1 - else: - tracking_dic['contributions']['external'] = tracking_dic['contributions']['external'] + 1 - - return tracking_dic - -def iterateContentIndexMdFiles(): - # set variables to track as we iterate - # weekly -> content: - weekly_count_dic = {'total': 0, 'cross-platform': 0, 'install-guides': 0} - for category in lp_and_ig_content_dirs: - weekly_count_dic[category] = 0 - - # weekly -> authors AND contributions - weekly_authors_contributions_dic = {'individual_authors': {}, 'contributions':{'internal': 0, 'external': 0}} - - # tests -> summary: - content_total = 0 - content_with_tests_enabled = 0 - content_with_all_tests_passing = 0 - - # start iterating over all sw_categories including install guides - for category in lp_and_ig_content_dirs: - new_tests_entry['sw_categories'][category] = {} # Add new category key - - # Get list of content to iterate over. - content_in_dir = [] - if category != 'install-guides': # Learning Path processing - category_dir = learning_path_dir.parent / (learning_path_dir.name + '/' + category) - content_in_dir = [ Path(f.path+"/_index.md") for f in os.scandir(category_dir) if f.is_dir() ] - - else: # Install Guide Processing. ### Get array of install guide files (everything that IS NOT an _index.md file; so count docker_desktop.md seperate than docker_woa.md under docker dir) - for ig in os.scandir(install_guide_dir): - if not ig.is_dir(): - # Append normal .md files - if ig.name != '_index.md': # ignore top level file - content_in_dir.append(Path(ig)) - else: # iterate over multi-layer files - if ig.name != '_images': # ignore image directory - for ig_part in os.scandir(ig): #iterate over all files in multiparge ig dir - if ig_part.name != '_index.md': # ignore top level file - content_in_dir.append(Path(ig_part)) - - - - - # Iterate over all content files - for content_index_file in content_in_dir: - content_metadic = mdToMetadata(content_index_file) - - # If draft, ignore by continuing right away to the next file - try: - if content_metadic['draft']: - continue - except: - pass - # If the example learning path, continue - if '_example-learning-path' in str(content_index_file.parent): - continue - - - # Add to content total (both tests and weekly places for redundency sake) - weekly_count_dic['total'] = weekly_count_dic['total'] + 1 - content_total = content_total + 1 - # Add to category total - weekly_count_dic[category] = weekly_count_dic[category] + 1 - - ######### AUTHOR info - weekly_authors_contributions_dic = authorAdd(content_metadic['author'],weekly_authors_contributions_dic) - - - # Record entry in test file - try: - if content_metadic['test_maintenance']: # if actively being tested, record as such - # Record test - content_with_tests_enabled = content_with_tests_enabled + 1 - - # Add an entry for this dir, with title and test status keys - if category == 'install-guides': # Install Guides, shorthand name is the .md file name itself (for multi-part installs, still the individual file name; dir name is ignored) - content_dir_name = content_index_file.stem - else: # Learning Paths, shorthand name is the directory - content_dir_name = os.path.basename(os.path.dirname(content_index_file)) - - new_tests_entry['sw_categories'][category][content_dir_name] = {} - new_tests_entry['sw_categories'][category][content_dir_name]['readable_title'] = content_metadic['title'] - new_tests_entry['sw_categories'][category][content_dir_name]['tests_and_status'] = [] - all_tests_passing = True # Default to true, change if one is false - for i, item in enumerate(content_metadic['test_status']): - # Record test status (possibily multiple) - new_tests_entry['sw_categories'][category][content_dir_name]['tests_and_status'].append({ - content_metadic['test_images'][i]: content_metadic['test_status'][i] - }) - if item != 'passed': - all_tests_passing = False - # Add if tests are passing count if all tests under this content are passing - if all_tests_passing: - content_with_all_tests_passing = content_with_all_tests_passing + 1 - except: - pass - - # Update all totals for tests passing or not into the summary - new_tests_entry['summary']['content_total'] = content_total - new_tests_entry['summary']['content_with_tests_enabled'] = content_with_tests_enabled - new_tests_entry['summary']['content_with_all_tests_passing'] = content_with_all_tests_passing - - # Update stats - new_weekly_entry['content'] = weekly_count_dic - new_weekly_entry['individual_authors'] = weekly_authors_contributions_dic['individual_authors'] - new_weekly_entry['contributions'] = weekly_authors_contributions_dic['contributions'] - -def callGitHubAPI(GitHub_token,GitHub_repo_name): - - weekly_github_dic = {'issues': {}, 'github_engagement': {}} - - - headers = { - 'Authorization': f'token {GitHub_token}', - 'Accept': 'application/vnd.github.v3+json' - } - url_issues = f'{GitHub_repo_name}issues' - url_pulls = f'{GitHub_repo_name}pulls' - url_forks = f'{GitHub_repo_name}forks' - - # Get Number of Forks - response = requests.get(url_forks, headers=headers) - if response.ok: - forks = response.json() - weekly_github_dic['github_engagement']['num_forks'] = len(forks) - else: - print(f'ERROR: Failed to fetch GitHub API forks: {url_forks} {response.status_code} {response.reason}') - sys.exit(1) - - # Get Number of Pull Requests - response = requests.get(url_pulls, headers=headers) - if response.ok: - pulls = response.json() - weekly_github_dic['github_engagement']['num_prs'] = len(pulls) - else: - print(f'ERROR: Failed to fetch GitHub API forks: {url_pulls} {response.status_code} {response.reason}') - sys.exit(1) - - # Get Issues information - response = requests.get(url_issues, headers=headers) - if response.ok: - issues = response.json() - - # Iterate over each issue and read the state - closed_num = 0 - time_differences = [] - for issue in issues: - if issue['state'] == 'closed': - # Increment number of closed - closed_num = closed_num + 1 - - # Get average time - created_at = datetime.fromisoformat(issue['created_at'][:-1]) - closed_at = datetime.fromisoformat(issue['closed_at'][:-1]) - difference = closed_at - created_at - time_differences.append(difference.total_seconds() / 3600) # Convert to hours - - print(issue['title'],issue['state']) - - # Calculate average time to close - if time_differences: - avg_time_to_close = sum(time_differences) / len(time_differences) - else: - avg_time_to_close = 0 - - # Store all stats in github dic - weekly_github_dic['issues']['num_issues'] = len(issues) - weekly_github_dic['issues']['percent_closed_vs_total'] = round( (closed_num/len(issues)) * 100, 1) - weekly_github_dic['issues']['avg_close_time_hrs'] = round(avg_time_to_close,1) - - else: - print(f'ERROR: Failed to fetch GitHub API issues: {url_issues} {response.status_code} {response.reason}') - sys.exit(1) - - - # Assign to main file - new_weekly_entry['issues'] = weekly_github_dic['issues'] - new_weekly_entry['github_engagement'] = weekly_github_dic['github_engagement'] - - -def main(): - global data_weekly_file_path, tests_status_file_path, learning_path_dir, install_guide_dir, date_today, new_weekly_entry, new_tests_entry - - # Read in params needed for reading GitHub API - arg_parser = argparse.ArgumentParser(description='Update Stats') - arg_parser.add_argument('-t','--token', help='GitHub personal access token', required=True) - arg_parser.add_argument('-r','--repo', help='GitHub repository name', required=True) - args = arg_parser.parse_args() - - - - # Read in data file as python dict - existing_weekly_dic = yaml.safe_load(data_weekly_file_path.read_text()) - existing_tests_dic = yaml.safe_load(tests_status_file_path.read_text()) - - # Structure new data formats: - new_weekly_entry = { - "a_date": date_today, - "content": {}, - "individual_authors": {}, - "contributions": {}, - "issues": {}, - "github_engagement": {} - } - - new_tests_entry = { - "summary": {}, - "sw_categories":{} - } - - - # Get new stats, filling in new stat dictionaries: - iterateContentIndexMdFiles() - callGitHubAPI(args.token, args.repo) - - - - # Debug prints in flow - printInfo(new_weekly_entry,new_tests_entry) - - # Update/replace yaml files - - ### Weekly - # if weekly dict is empty, create key - if not existing_weekly_dic: - print('no existing dic, starting from scratch.') - existing_weekly_dic = [new_weekly_entry] - # Otherwise append it - else: - print('weekly data exists...checking to see if date exists.') - # Check if date already a key in there - exists=False - for dic in existing_weekly_dic: - if date_today == dic["a_date"]: - print('date today included, don"t save') - exists=True - break - if not exists: - print('date doesn"t exist, appending data') - existing_weekly_dic.append(new_weekly_entry) - - # Alter existing dic to be a list of dates for easier processing: - with open(data_weekly_file_path, 'w') as outfile: - print('printing weekly dict format, and dumping into this file: ') - print(outfile) - print(existing_weekly_dic) - yaml.dump(existing_weekly_dic, outfile, default_flow_style=False) - - ### Tests - existing_tests_dic = new_tests_entry - with open(tests_status_file_path, 'w') as outfile: - yaml.dump(existing_tests_dic, outfile, default_flow_style=False) - -if __name__ == "__main__": - main() From aa4e8bd6de75fbb33dda78b5a21bf4217b8ec8b4 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 12:54:27 +0000 Subject: [PATCH 16/21] fixed file name --- .../openadkit2_safetyisolation/{1c_ISO26262.md => 1c_iso26262.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/learning-paths/automotive/openadkit2_safetyisolation/{1c_ISO26262.md => 1c_iso26262.md} (100%) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1c_iso26262.md similarity index 100% rename from content/learning-paths/automotive/openadkit2_safetyisolation/1c_ISO26262.md rename to content/learning-paths/automotive/openadkit2_safetyisolation/1c_iso26262.md From 9e5e2f99982d2e7ddec12148b2607d2cbca5a133 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 12:59:55 +0000 Subject: [PATCH 17/21] Removed clutter --- tools/style_rules.json | 577 ----------------------------------------- 1 file changed, 577 deletions(-) delete mode 100644 tools/style_rules.json diff --git a/tools/style_rules.json b/tools/style_rules.json deleted file mode 100644 index c4967a956c..0000000000 --- a/tools/style_rules.json +++ /dev/null @@ -1,577 +0,0 @@ -[ - { - "pattern": "\\butilize\\b", - "replacement": "use", - "reason": "Use 'use' instead of 'utilize' for simplicity." - }, - { - "pattern": "\\butilizes\\b", - "replacement": "uses", - "reason": "Use 'uses' instead of 'utilizes' for simplicity." - }, - { - "pattern": "\\butilized\\b", - "replacement": "used", - "reason": "Use 'used' instead of 'utilized' for simplicity." - }, - { - "pattern": "\\butilizing\\b", - "replacement": "using", - "reason": "Use 'using' instead of 'utilizing' for simplicity." - }, - { - "pattern": "\\butilization\\b", - "replacement": "use", - "reason": "Use 'use' instead of 'utilization' for simplicity." - }, - { - "pattern": "\\boptimize\\b", - "replacement": "improve", - "reason": "Simplify language by replacing 'optimize' with 'improve'." - }, - { - "pattern": "\\boptimizes\\b", - "replacement": "improves", - "reason": "Simplify language by replacing 'optimizes' with 'improves'." - }, - { - "pattern": "\\boptimized\\b", - "replacement": "improved", - "reason": "Simplify language by replacing 'optimized' with 'improved'." - }, - { - "pattern": "\\boptimizing\\b", - "replacement": "improving", - "reason": "Simplify language by replacing 'optimizing' with 'improving'." - }, - { - "pattern": "\\boptimization\\b", - "replacement": "improvement", - "reason": "Simplify language by replacing 'optimization' with 'improvement'." - }, - { - "pattern": "\\boptimizations\\b", - "replacement": "improvements", - "reason": "Simplify language by replacing 'optimizations' with 'improvements'." - }, - { - "pattern": "\\bin order to\\b", - "replacement": "to", - "reason": "Use 'to' instead of 'in order to' for conciseness." - }, - { - "pattern": "\\bplease note that\\b", - "replacement": "", - "reason": "Remove 'please note that' for directness." - }, - { - "pattern": "\\byou should\\b", - "replacement": "", - "reason": "Be direct with instructions, avoid 'you should'." - }, - { - "pattern": "\\bis able to\\b", - "replacement": "can", - "reason": "Use 'can' instead of 'is able to' for simplicity." - }, - { - "pattern": "\\bare able to\\b", - "replacement": "can", - "reason": "Use 'can' instead of 'are able to' for simplicity." - }, - { - "pattern": "\\bwas able to\\b", - "replacement": "could", - "reason": "Use 'could' instead of 'was able to' for simplicity." - }, - { - "pattern": "\\bwere able to\\b", - "replacement": "could", - "reason": "Use 'could' instead of 'were able to' for simplicity." - }, - { - "pattern": "\\bdue to the fact that\\b", - "replacement": "because", - "reason": "Use 'because' instead of 'due to the fact that' for conciseness." - }, - { - "pattern": "\\bat this point in time\\b", - "replacement": "now", - "reason": "Use 'now' instead of 'at this point in time' for conciseness." - }, - { - "pattern": "\\bfor the purpose of\\b", - "replacement": "for", - "reason": "Use 'for' instead of 'for the purpose of' for conciseness." - }, - { - "pattern": "\\bprior to\\b", - "replacement": "before", - "reason": "Use 'before' instead of 'prior to' for simplicity." - }, - { - "pattern": "\\bsubsequent to\\b", - "replacement": "after", - "reason": "Use 'after' instead of 'subsequent to' for simplicity." - }, - { - "pattern": "\\ba large number of\\b", - "replacement": "many", - "reason": "Use 'many' instead of 'a large number of' for conciseness." - }, - { - "pattern": "\\ba majority of\\b", - "replacement": "most", - "reason": "Use 'most' instead of 'a majority of' for conciseness." - }, - { - "pattern": "\\bin spite of\\b", - "replacement": "despite", - "reason": "Use 'despite' instead of 'in spite of' for conciseness." - }, - { - "pattern": "\\bwith regard to\\b", - "replacement": "about", - "reason": "Use 'about' instead of 'with regard to' for conciseness." - }, - { - "pattern": "\\bwith respect to\\b", - "replacement": "about", - "reason": "Use 'about' instead of 'with respect to' for conciseness." - }, - { - "pattern": "\\bwe recommend\\b", - "replacement": "it is recommended", - "reason": "Use 'it is recommended' instead of 'we recommend' for a more neutral tone." - }, - { - "pattern": "\\bwe suggest\\b", - "replacement": "it is suggested", - "reason": "Use 'it is suggested' instead of 'we suggest' for a more neutral tone." - }, - { - "pattern": "\\bwe advise\\b", - "replacement": "it is advised", - "reason": "Use 'it is advised' instead of 'we advise' for a more neutral tone." - }, - { - "pattern": "\\bwe will\\b", - "replacement": "you will", - "reason": "Use 'you will' instead of 'we will' to address the reader directly." - }, - { - "pattern": "\\bwe can\\b", - "replacement": "you can", - "reason": "Use 'you can' instead of 'we can' to address the reader directly." - }, - { - "pattern": "\\bwe have\\b", - "replacement": "you have", - "reason": "Use 'you have' instead of 'we have' to address the reader directly." - }, - { - "pattern": "\\bwe are\\b", - "replacement": "you are", - "reason": "Use 'you are' instead of 'we are' to address the reader directly." - }, - { - "pattern": "\\bwe need to\\b", - "replacement": "you need to", - "reason": "Use 'you need to' instead of 'we need to' to address the reader directly." - }, - { - "pattern": "\\bwe must\\b", - "replacement": "you must", - "reason": "Use 'you must' instead of 'we must' to address the reader directly." - }, - { - "pattern": "\\bwe should\\b", - "replacement": "you should", - "reason": "Use 'you should' instead of 'we should' to address the reader directly." - }, - { - "pattern": "\\bis processed by\\b", - "replacement": "processes", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bare processed by\\b", - "replacement": "process", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwas processed by\\b", - "replacement": "processed", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwere processed by\\b", - "replacement": "processed", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bis handled by\\b", - "replacement": "handles", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bare handled by\\b", - "replacement": "handle", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwas handled by\\b", - "replacement": "handled", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwere handled by\\b", - "replacement": "handled", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bis managed by\\b", - "replacement": "manages", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bare managed by\\b", - "replacement": "manage", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwas managed by\\b", - "replacement": "managed", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwere managed by\\b", - "replacement": "managed", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bis created by\\b", - "replacement": "creates", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bare created by\\b", - "replacement": "create", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwas created by\\b", - "replacement": "created", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwere created by\\b", - "replacement": "created", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bis generated by\\b", - "replacement": "generates", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bare generated by\\b", - "replacement": "generate", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwas generated by\\b", - "replacement": "generated", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwere generated by\\b", - "replacement": "generated", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bis provided by\\b", - "replacement": "provides", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bare provided by\\b", - "replacement": "provide", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwas provided by\\b", - "replacement": "provided", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bwere provided by\\b", - "replacement": "provided", - "reason": "Use active voice instead of passive voice." - }, - { - "pattern": "\\bARM\\b", - "replacement": "Arm", - "reason": "Use 'Arm' instead of 'ARM' for clarity or consistency." - }, - { - "pattern": "\\bARM's\\b", - "replacement": "Arm's", - "reason": "Use 'Arm's' instead of 'ARM's' for clarity or consistency." - }, - { - "pattern": "\\badaptor\\b", - "replacement": "adapter", - "reason": "Use 'adapter' instead of 'adaptor' for clarity or consistency." - }, - { - "pattern": "\\banalyse\\b", - "replacement": "analyze", - "reason": "Use 'analyze' instead of 'analyse' for clarity or consistency." - }, - { - "pattern": "\\bback\\-end\\b", - "replacement": "backend", - "reason": "Use 'backend' instead of 'back-end' for clarity or consistency." - }, - { - "pattern": "\\bcustom\\-made\\b", - "replacement": "custom-built", - "reason": "Use 'custom-built' instead of 'custom-made' for clarity or consistency." - }, - { - "pattern": "\\bdouble\\-click\\b", - "replacement": "double-tap", - "reason": "Use 'double-tap' instead of 'double-click' for clarity or consistency." - }, - { - "pattern": "\\beasy\\ to\\ use\\b", - "replacement": "easy-to-use", - "reason": "Use 'easy-to-use' instead of 'easy to use' for clarity or consistency." - }, - { - "pattern": "\\beliminate\\b", - "replacement": "remove", - "reason": "Use 'remove' instead of 'eliminate' for clarity or consistency." - }, - { - "pattern": "\\bextract\\b", - "replacement": "remove", - "reason": "Use 'remove' instead of 'extract' for clarity or consistency." - }, - { - "pattern": "\\btake\\ away\\b", - "replacement": "remove", - "reason": "Use 'remove' instead of 'take away' for clarity or consistency." - }, - { - "pattern": "\\be\\.g\\.\\b", - "replacement": "for example", - "reason": "Use 'for example' instead of 'e.g.' for clarity or consistency." - }, - { - "pattern": "\\bi\\.e\\.\\b", - "replacement": "that is", - "reason": "Use 'that is' instead of 'i.e.' for clarity or consistency." - }, - { - "pattern": "\\bergo\\b", - "replacement": "therefore", - "reason": "Use 'therefore' instead of 'ergo' for clarity or consistency." - }, - { - "pattern": "\\bdo\\ not\\b", - "replacement": "don't", - "reason": "Use 'don't' instead of 'do not' for clarity or consistency." - }, - { - "pattern": "\\bit\\ is\\b", - "replacement": "it's", - "reason": "Use 'it's' instead of 'it is' for clarity or consistency." - }, - { - "pattern": "\\bis\\ not\\b", - "replacement": "isn't", - "reason": "Use 'isn't' instead of 'is not' for clarity or consistency." - }, - { - "pattern": "\\bthat\\ is\\b", - "replacement": "that's", - "reason": "Use 'that's' instead of 'that is' for clarity or consistency." - }, - { - "pattern": "\\bviz\\.\\b", - "replacement": "namely", - "reason": "Use 'namely' instead of 'viz.' for clarity or consistency." - }, - { - "pattern": "\\btry\\ not\\ to\\b", - "replacement": "avoid", - "reason": "Use 'avoid' instead of 'try not to' for clarity or consistency." - }, - { - "pattern": "\\brefer\\ to\\b", - "replacement": "see", - "reason": "Use 'see' instead of 'refer to' for clarity or consistency." - }, - { - "pattern": "\\bsub\\-optimal\\b", - "replacement": "suboptimal", - "reason": "Use 'suboptimal' instead of 'sub-optimal' for clarity or consistency." - }, - { - "pattern": "\\bserver\\-less\\b", - "replacement": "serverless", - "reason": "Use 'serverless' instead of 'server-less' for clarity or consistency." - }, - { - "pattern": "\\btouch\\ screen\\b", - "replacement": "touchscreen", - "reason": "Use 'touchscreen' instead of 'touch screen' for clarity or consistency." - }, - { - "pattern": "\\bctrl\\ key\\b", - "replacement": "Ctrl key", - "reason": "Use 'Ctrl key' instead of 'ctrl key' for clarity or consistency." - }, - { - "pattern": "\\bspot\\b", - "replacement": "identify", - "reason": "Use 'identify' instead of 'spot' for clarity or consistency." - }, - { - "pattern": "\\bleverage\\b", - "replacement": "take advantage of", - "reason": "Use 'take advantage of' instead of 'leverage' for clarity or consistency." - }, - { - "pattern": "\\blicence\\b", - "replacement": "license", - "reason": "Use 'license' instead of 'licence' for clarity or consistency." - }, - { - "pattern": "\\bmassive\\b", - "replacement": "significant", - "reason": "Use 'significant' instead of 'massive' for clarity or consistency." - }, - { - "pattern": "\\brespond\\ to\\ the\\ ask\\b", - "replacement": "respond to the request", - "reason": "Use 'respond to the request' instead of 'respond to the ask' for clarity or consistency." - }, - { - "pattern": "\\brevert\\ back\\ to\\b", - "replacement": "revert to", - "reason": "Use 'revert to' instead of 'revert back to' for clarity or consistency." - }, - { - "pattern": "\\bpower\\ off\\b", - "replacement": "turn off", - "reason": "Use 'turn off' instead of 'power off' for clarity or consistency." - }, - { - "pattern": "\\bpower\\ on\\b", - "replacement": "turn on", - "reason": "Use 'turn on' instead of 'power on' for clarity or consistency." - }, - { - "pattern": "\\bpress\\b", - "replacement": "select", - "reason": "Use 'select' instead of 'press' for clarity or consistency." - }, - { - "pattern": "\\bsmart\\ technology\\b", - "replacement": "intelligent technology", - "reason": "Use 'intelligent technology' instead of 'smart technology' for clarity or consistency." - }, - { - "pattern": "\\blearning\\ path\\b", - "replacement": "Learning Path", - "reason": "Use 'Learning Path' instead of 'learning path' for clarity or consistency." - }, - { - "pattern": "\\bwearable\\b", - "replacement": "wearable device", - "reason": "Use 'wearable device' instead of 'wearable' for clarity or consistency." - }, - { - "pattern": "\\bGB\\ per\\ second\\b", - "replacement": "Gbps", - "reason": "Use 'Gbps' instead of 'GB per second' for clarity or consistency." - }, - { - "pattern": "\\bkey\\ combination\\b", - "replacement": "keyboard shortcut", - "reason": "Use 'keyboard shortcut' instead of 'key combination' for clarity or consistency." - }, - { - "pattern": "\\blearn\\ how\\ to\\ use\\b", - "replacement": "use", - "reason": "Use 'use' instead of 'learn how to use' for clarity or consistency." - }, - { - "pattern": "\\brequire\\b", - "replacement": "need", - "reason": "Use 'need' instead of 'require' for clarity or consistency." - }, - { - "pattern": "\\bFollow\\ the\\ steps\\ below\\ to\\b", - "replacement": "To", - "reason": "Use 'To' instead of 'Follow the steps below to' for clarity or consistency." - }, - { - "pattern": "\\bwe\\ observe\\b", - "replacement": "you can see", - "reason": "Use 'you can see' instead of 'we observe' for clarity or consistency." - }, - { - "pattern": "\\bmay\\b", - "replacement": "can", - "reason": "Use 'can' instead of 'may' for clarity or consistency." - }, - { - "pattern": "\\bwould\\b", - "replacement": "does", - "reason": "Use 'does' instead of 'would' for clarity or consistency." - }, - { - "pattern": "\\bwe\\b", - "replacement": "you", - "reason": "Use 'you' instead of 'we' for clarity or consistency." - }, - { - "pattern": "\\byou\\ are\\b", - "replacement": "you're", - "reason": "Use 'you're' instead of 'you are' for clarity or consistency." - }, - { - "pattern": "\\byou\\ will\\b", - "replacement": "you'll", - "reason": "Use 'you'll' instead of 'you will' for clarity or consistency." - }, - { - "pattern": "\\bCloud\\ Native\\b", - "replacement": "cloud native", - "reason": "Use 'cloud native' instead of 'Cloud Native' for clarity or consistency." - }, - { - "pattern": "\\bseeking\\ to\\b", - "replacement": "looking to", - "reason": "Use 'looking to' instead of 'seeking to' for clarity or consistency." - }, - { - "pattern": "\\bsince\\b", - "replacement": "because", - "reason": "Use 'because' instead of 'since' for clarity or consistency." - }, - { - "pattern": "\\bin\\ addition\\b", - "replacement": "also", - "reason": "Use 'also' instead of 'in addition' for clarity or consistency." - }, - { - "pattern": "\\bimpact\\ performance\\b", - "replacement": "affect performance", - "reason": "Use 'affect performance' instead of 'impact performance' for clarity or consistency." - } -] \ No newline at end of file From 39d8ff7bf435d9c923632a8eabb9ed022a0d36ba Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 13:05:55 +0000 Subject: [PATCH 18/21] fixed file name --- ...nt functional_safety.md => 1e_implement_ functional_safety.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/learning-paths/automotive/openadkit2_safetyisolation/{1e_implement functional_safety.md => 1e_implement_ functional_safety.md} (100%) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_ functional_safety.md similarity index 100% rename from content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement functional_safety.md rename to content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_ functional_safety.md From 1511eb7f083dd7a76a9e9121e3a6947a6b2b49f8 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 13:12:46 +0000 Subject: [PATCH 19/21] final time lucky! --- ...nt_ functional_safety.md => 1e_implement_functional_safety.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/learning-paths/automotive/openadkit2_safetyisolation/{1e_implement_ functional_safety.md => 1e_implement_functional_safety.md} (100%) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_ functional_safety.md b/content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_functional_safety.md similarity index 100% rename from content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_ functional_safety.md rename to content/learning-paths/automotive/openadkit2_safetyisolation/1e_implement_functional_safety.md From 632ef245e538061d4a9cf03b058cba22942cf84b Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Thu, 24 Jul 2025 15:13:50 +0100 Subject: [PATCH 20/21] Add files via upload --- tools/stats_data_generate.py | 432 +++++++++++++++++++++++++++++++++++ 1 file changed, 432 insertions(+) create mode 100644 tools/stats_data_generate.py diff --git a/tools/stats_data_generate.py b/tools/stats_data_generate.py new file mode 100644 index 0000000000..cb1dd571c0 --- /dev/null +++ b/tools/stats_data_generate.py @@ -0,0 +1,432 @@ +# Next steps: +# Add 'cross platform' into category checking and addition +# Record same for install guides +# Verify test data & totals matches reality +# -------- move on to individual_authors&contributors +# -------- move on to GitHub API + + + +''' +Goal: Every week, update the stats_data.yml file automatically by reading the current state and GitHub API + +Steps: + 1) Read in stats_data.yml as a python dict + 2) Verify we can read in new stats, via a function for each datapoint to log + 2a) Directory structure read + 2b) GitHub API obtain data + 3) If we have new data, append to stats_data.yml. If not, fail script to notify GitHub folks +''' + +''' +weekly_in_YYYY_MMM_DD: + 2023-Mar-03: # Date, updated weekly, in YYYY-MMM-DD format + content: # Dict of content related stats. Source: # of LP in each directory + total: 33 # raw sum of all all below + ucontroller: 5 + embedded: 2 + desktop: 1 + server: 10 + mobile: 3 + cross: 2 # Number of learning paths in cross-platform area; for awareness + install_guides: 10 + individual_authors: # Dict of author stats. Source: Crawl over each LP and IG, urlize author name, and add totals + jason_andrews: 24 + pareena_verma: 22 + ronan_synnott: 15 + florent_lebeau: 9 + jane_doe: 2 + john_smith: 2 + contributions: # Dict of contribution stats. Source: Cross-match found author names in LPs and IGs with 'contributors.csv' to identify them as internal (with company Arm) or external (all others) + internal: 70 + external: 4 + issues: # Dict of GitHub issues raised in this repo. Source: GitHub API + avg_close_time_hrs: 42 + percent_closed_vs_total: 90.5 + num_issues: 66 + github_engagement: # Dict of GitHub repo webpage engagement numbers. Source: GitHub API + num_prs: 34 + num_forks: 20 +''' + + +''' +--- +summary: # Basic summary of tests in this site. Source: adding numbers when iterating over sw_categories below + content_total: 30 + content_with_tests_enabled: 10 # Will match the number of learning paths + content_with_all_tests_passing: 9 + + +sw_categories: # Dict of content test status. Source: Iterate over each LP category and IGs _index.md files to scrape data and store in this one place. + server: + intrinsics: + title: Integrate Intrinsics here + tests_and_status: + - amd64/ubuntu:latest: passed + - arm64v8/ubuntu:latest: passed + avh_cicd: + title: AVH Title + tests_and_status: + - RPi3:latest: passed +''' + + + +import os +import sys +import csv +import yaml +import argparse +import requests +from pathlib import Path +from datetime import datetime + + +# Set paths +data_weekly_file_path = Path('../data/stats_weekly_data.yml') +tests_status_file_path = Path('../data/stats_current_test_info.yml') +learning_path_dir = Path('../content/learning-paths/') +install_guide_dir = Path('../content/install-guides/') +lp_and_ig_content_dirs = ['embedded-and-microcontrollers','iot','laptops-and-desktops','servers-and-cloud-computing','mobile-graphics-and-gaming','automotive','cross-platform','install-guides'] + + +# Obtain today's date in YYYY-MM-DD +date_today = datetime.now().strftime("%Y-%m-%d") + +# Set global vars for processing ease +new_weekly_entry = {} +new_tests_entry = {} + +############################################################################# +############################################################################# + + +def pretty(d, indent=0): + for key, value in d.items(): + print('\t' * indent + str(key)) + if isinstance(value, dict): + pretty(value, indent+1) + else: + print('\t' * (indent+1) + str(value)) + +def printInfo(week,test): + print('============================================================================') + print('New weekly entry dict appended:') + pretty(week) + print('============================================================================') + print('New test entry dict overwriting:') + pretty(test) + print('============================================================================') + + +def urlize(in_str): + # Replacate Hugo urlize function to make it easier to process strings for consistent analysis. + # ' ' -> '-' + # capitals -> lowercase + return in_str.replace(' ','-').lower() + +def mdToMetadata(md_file_path): + metadata_text = "" + content_text = "" + inMetadata = False + + # Remove last '---' to propery read in yaml metadata component of .md file + with open(md_file_path, encoding="utf8") as f: + for line in (f.readlines()): + if ('---' in line) and inMetadata: + break # go on when needed to gather content text + elif ('---' in line) and (not inMetadata): + inMetadata = True + metadata_text += line + + # Load yaml + metadata_dic = yaml.safe_load(metadata_text) + return metadata_dic + +def authorAdd(author_names,tracking_dic): + ### Update 'individual_authors' area, raw number by each author. + + # Support multiple authors by iterating through a list. + # First, check if author_name is a list or not. If not, make it a list + if not isinstance(author_names, list): + author_names = [author_names] + for author_name in author_names: + + # Check if author already exists as key. If not, add new key + author_urlized = urlize(author_name) + if author_urlized in tracking_dic['individual_authors']: + # Update number for this author + tracking_dic['individual_authors'][author_urlized] = tracking_dic['individual_authors'][author_urlized] + 1 + else: + # Add key to dic with 1 to their name + tracking_dic['individual_authors'][author_urlized] = 1 + + ### Update 'contributions' area, internal vs external contributions + + # open the contributors CSV file + with open('../assets/contributors.csv', mode ='r')as file: + csvFile = csv.reader(file) + for line in csvFile: + company = line[1] + # If author in the line, check if they work at Arm or not, and increment contributions number for internal or external + if author_name in line: + if company == 'Arm': + tracking_dic['contributions']['internal'] = tracking_dic['contributions']['internal'] + 1 + else: + tracking_dic['contributions']['external'] = tracking_dic['contributions']['external'] + 1 + + return tracking_dic + +def iterateContentIndexMdFiles(): + # set variables to track as we iterate + # weekly -> content: + weekly_count_dic = {'total': 0, 'cross-platform': 0, 'install-guides': 0} + for category in lp_and_ig_content_dirs: + weekly_count_dic[category] = 0 + + # weekly -> authors AND contributions + weekly_authors_contributions_dic = {'individual_authors': {}, 'contributions':{'internal': 0, 'external': 0}} + + # tests -> summary: + content_total = 0 + content_with_tests_enabled = 0 + content_with_all_tests_passing = 0 + + # start iterating over all sw_categories including install guides + for category in lp_and_ig_content_dirs: + new_tests_entry['sw_categories'][category] = {} # Add new category key + + # Get list of content to iterate over. + content_in_dir = [] + if category != 'install-guides': # Learning Path processing + category_dir = learning_path_dir.parent / (learning_path_dir.name + '/' + category) + content_in_dir = [ Path(f.path+"/_index.md") for f in os.scandir(category_dir) if f.is_dir() ] + + else: # Install Guide Processing. ### Get array of install guide files (everything that IS NOT an _index.md file; so count docker_desktop.md seperate than docker_woa.md under docker dir) + for ig in os.scandir(install_guide_dir): + if not ig.is_dir(): + # Append normal .md files + if ig.name != '_index.md': # ignore top level file + content_in_dir.append(Path(ig)) + else: # iterate over multi-layer files + if ig.name != '_images': # ignore image directory + for ig_part in os.scandir(ig): #iterate over all files in multiparge ig dir + if ig_part.name != '_index.md': # ignore top level file + content_in_dir.append(Path(ig_part)) + + + + + # Iterate over all content files + for content_index_file in content_in_dir: + content_metadic = mdToMetadata(content_index_file) + + # If draft, ignore by continuing right away to the next file + try: + if content_metadic['draft']: + continue + except: + pass + # If the example learning path, continue + if '_example-learning-path' in str(content_index_file.parent): + continue + + + # Add to content total (both tests and weekly places for redundency sake) + weekly_count_dic['total'] = weekly_count_dic['total'] + 1 + content_total = content_total + 1 + # Add to category total + weekly_count_dic[category] = weekly_count_dic[category] + 1 + + ######### AUTHOR info + weekly_authors_contributions_dic = authorAdd(content_metadic['author'],weekly_authors_contributions_dic) + + + # Record entry in test file + try: + if content_metadic['test_maintenance']: # if actively being tested, record as such + # Record test + content_with_tests_enabled = content_with_tests_enabled + 1 + + # Add an entry for this dir, with title and test status keys + if category == 'install-guides': # Install Guides, shorthand name is the .md file name itself (for multi-part installs, still the individual file name; dir name is ignored) + content_dir_name = content_index_file.stem + else: # Learning Paths, shorthand name is the directory + content_dir_name = os.path.basename(os.path.dirname(content_index_file)) + + new_tests_entry['sw_categories'][category][content_dir_name] = {} + new_tests_entry['sw_categories'][category][content_dir_name]['readable_title'] = content_metadic['title'] + new_tests_entry['sw_categories'][category][content_dir_name]['tests_and_status'] = [] + all_tests_passing = True # Default to true, change if one is false + for i, item in enumerate(content_metadic['test_status']): + # Record test status (possibily multiple) + new_tests_entry['sw_categories'][category][content_dir_name]['tests_and_status'].append({ + content_metadic['test_images'][i]: content_metadic['test_status'][i] + }) + if item != 'passed': + all_tests_passing = False + # Add if tests are passing count if all tests under this content are passing + if all_tests_passing: + content_with_all_tests_passing = content_with_all_tests_passing + 1 + except: + pass + + # Update all totals for tests passing or not into the summary + new_tests_entry['summary']['content_total'] = content_total + new_tests_entry['summary']['content_with_tests_enabled'] = content_with_tests_enabled + new_tests_entry['summary']['content_with_all_tests_passing'] = content_with_all_tests_passing + + # Update stats + new_weekly_entry['content'] = weekly_count_dic + new_weekly_entry['individual_authors'] = weekly_authors_contributions_dic['individual_authors'] + new_weekly_entry['contributions'] = weekly_authors_contributions_dic['contributions'] + +def callGitHubAPI(GitHub_token,GitHub_repo_name): + + weekly_github_dic = {'issues': {}, 'github_engagement': {}} + + + headers = { + 'Authorization': f'token {GitHub_token}', + 'Accept': 'application/vnd.github.v3+json' + } + url_issues = f'{GitHub_repo_name}issues' + url_pulls = f'{GitHub_repo_name}pulls' + url_forks = f'{GitHub_repo_name}forks' + + # Get Number of Forks + response = requests.get(url_forks, headers=headers) + if response.ok: + forks = response.json() + weekly_github_dic['github_engagement']['num_forks'] = len(forks) + else: + print(f'ERROR: Failed to fetch GitHub API forks: {url_forks} {response.status_code} {response.reason}') + sys.exit(1) + + # Get Number of Pull Requests + response = requests.get(url_pulls, headers=headers) + if response.ok: + pulls = response.json() + weekly_github_dic['github_engagement']['num_prs'] = len(pulls) + else: + print(f'ERROR: Failed to fetch GitHub API forks: {url_pulls} {response.status_code} {response.reason}') + sys.exit(1) + + # Get Issues information + response = requests.get(url_issues, headers=headers) + if response.ok: + issues = response.json() + + # Iterate over each issue and read the state + closed_num = 0 + time_differences = [] + for issue in issues: + if issue['state'] == 'closed': + # Increment number of closed + closed_num = closed_num + 1 + + # Get average time + created_at = datetime.fromisoformat(issue['created_at'][:-1]) + closed_at = datetime.fromisoformat(issue['closed_at'][:-1]) + difference = closed_at - created_at + time_differences.append(difference.total_seconds() / 3600) # Convert to hours + + print(issue['title'],issue['state']) + + # Calculate average time to close + if time_differences: + avg_time_to_close = sum(time_differences) / len(time_differences) + else: + avg_time_to_close = 0 + + # Store all stats in github dic + weekly_github_dic['issues']['num_issues'] = len(issues) + weekly_github_dic['issues']['percent_closed_vs_total'] = round( (closed_num/len(issues)) * 100, 1) + weekly_github_dic['issues']['avg_close_time_hrs'] = round(avg_time_to_close,1) + + else: + print(f'ERROR: Failed to fetch GitHub API issues: {url_issues} {response.status_code} {response.reason}') + sys.exit(1) + + + # Assign to main file + new_weekly_entry['issues'] = weekly_github_dic['issues'] + new_weekly_entry['github_engagement'] = weekly_github_dic['github_engagement'] + + +def main(): + global data_weekly_file_path, tests_status_file_path, learning_path_dir, install_guide_dir, date_today, new_weekly_entry, new_tests_entry + + # Read in params needed for reading GitHub API + arg_parser = argparse.ArgumentParser(description='Update Stats') + arg_parser.add_argument('-t','--token', help='GitHub personal access token', required=True) + arg_parser.add_argument('-r','--repo', help='GitHub repository name', required=True) + args = arg_parser.parse_args() + + + + # Read in data file as python dict + existing_weekly_dic = yaml.safe_load(data_weekly_file_path.read_text()) + existing_tests_dic = yaml.safe_load(tests_status_file_path.read_text()) + + # Structure new data formats: + new_weekly_entry = { + "a_date": date_today, + "content": {}, + "individual_authors": {}, + "contributions": {}, + "issues": {}, + "github_engagement": {} + } + + new_tests_entry = { + "summary": {}, + "sw_categories":{} + } + + + # Get new stats, filling in new stat dictionaries: + iterateContentIndexMdFiles() + callGitHubAPI(args.token, args.repo) + + + + # Debug prints in flow + printInfo(new_weekly_entry,new_tests_entry) + + # Update/replace yaml files + + ### Weekly + # if weekly dict is empty, create key + if not existing_weekly_dic: + print('no existing dic, starting from scratch.') + existing_weekly_dic = [new_weekly_entry] + # Otherwise append it + else: + print('weekly data exists...checking to see if date exists.') + # Check if date already a key in there + exists=False + for dic in existing_weekly_dic: + if date_today == dic["a_date"]: + print('date today included, don"t save') + exists=True + break + if not exists: + print('date doesn"t exist, appending data') + existing_weekly_dic.append(new_weekly_entry) + + # Alter existing dic to be a list of dates for easier processing: + with open(data_weekly_file_path, 'w') as outfile: + print('printing weekly dict format, and dumping into this file: ') + print(outfile) + print(existing_weekly_dic) + yaml.dump(existing_weekly_dic, outfile, default_flow_style=False) + + ### Tests + existing_tests_dic = new_tests_entry + with open(tests_status_file_path, 'w') as outfile: + yaml.dump(existing_tests_dic, outfile, default_flow_style=False) + +if __name__ == "__main__": + main() From bf39a134a0381ca9634e6e6177fae2846568b72a Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 24 Jul 2025 15:44:51 +0000 Subject: [PATCH 21/21] Added commenting in code to address review comments. --- .../openadkit2_safetyisolation/3_container_spliting.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md index 6c5809f0cd..b4db0659d8 100644 --- a/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md +++ b/content/learning-paths/automotive/openadkit2_safetyisolation/3_container_spliting.md @@ -124,7 +124,8 @@ Copy the following configuration into docker/cycloneDDS.xml on both machines, an 1000 auto - + + @@ -304,6 +305,7 @@ This will simulate outbound DDS traffic from the planning-control container. Set the required environment variables and launch the planning-control container: ```bash +# Replace this path with the location where you cloned the repository, if different export SCRIPT_DIR=/home/ubuntu/openadkit_demo.autoware/docker export CONF_FILE=$SCRIPT_DIR/etc/simulation/config/fail_static_obstacle_avoidance.param.yaml export COMMON_FILE=$SCRIPT_DIR/etc/simulation/config/common.param.yaml