Perhaps it is time for us to take a pause, and think about what we are doing.

What are we, as ordinary software engineers and developers to do? Many are afraid of being “left behind”, as our social media feeds are flooded with success stories of engineers deploying Claude and similar models. Power users are running thousands of agents simultaneously across huge code repositories. Then we read the horror stories of AI agents escaping their safety barriers and gaining control of machines belonging to other companies.

However, this is not a “doom and gloom” article, quite the opposite.

At Pathway Technologies we believe that there is another road (a “pathway”, if you like), where the best of human capabilities can be augmented by the best of AI. We have been hard at work on our concept of “The AI-Augmented Engineer”, where engineers can gain from their use of AI, without the loss of engineering discipline. Pathway Technologies is a standards and compliance focused company, so we are highly dependent on procedures and best engineering practices. However, software development in the 21st Century follows a well-established pattern that should be familiar to most developers, even those not working in industries requiring strict compliance:

• We are probably all using git (or another code repository), with good engineering discipline in the use of feature branches. Tools like gitlab and github allow us to follow a process of code review, automated testing and merge requests so that the main development branch remains clean.
• The human code review, combined with static analysis tools, forms the backbone of a strong review process.
• A well-maintained test suite with good code coverage allows for regression testing before any changes are committed to the main branch.

The key principle behind the AI-Augmented Engineer is that software development before AI got involved was based on the principle that humans make mistakes, and we developed ways of working to address this. We had teams of engineers, with junior and senior developers, and we mentored junior developers to help them to hone their skills. None of that should change now that we have AI in our toolbox.

We do need to recognise that AI tools are different from traditional, deterministic tools, and we do need to learn new ways to work with them. Perhaps the answer is to treat AI-enabled tools the same way we might treat a junior developer: we apply the same review, testing and analysis methods, and ensure that ultimately, the responsibility lies in the hands of a human engineer.

We can regain control of software development, not by jumping into AI blindly, hoping that it produces top-quality code. Rather, we should recognise that AI tools can be excellent at:

• Basic implementation
• Refactoring and the inevitable repair that follows
• Boilerplate generation
• Drafting documentation

AI-driven tools can significantly lower the cost of implementation, but humans still bring something that AI cannot. We have seen this at Pathway Technologies, as we have been implementing these ideas.

Engineering judgement remains vital in our industry, and this is where our human uniqueness and excellence now have room to grow:

• System modelling and architecture
• Providing experience-based engineering judgement
• Making connections with our inherently creative minds

We should not ignore AI, but neither should we fear it. It is another tool, and like all tools, it allows us to achieve far more than we can achieve without it. The future does not belong to engineers who ignore AI, and neither does it belong to those who blindly embrace it. Rather, the future belongs to those who learn to combine human judgement with AI’s capabilities.

Come on in, the water’s fine.

This is a cautionary tale for anyone using Large Language Models, such as CoPilot, to carry out research, particularly where the required information is not publicly and freely available on the Internet. On the day in question I was interested in the relationship between the IEC 61508 Functional Safety Standard and Quality Management (QM) systems. The issue is that QM systems are often discussed in the context of Functional Safety, but the standard lacks a clear, definitive statement on the subject.

So, I asked CoPilot a question:

Where does IEC 61508 state the need for a quality process?

CoPilot began its response with a bold assertion:

IEC 61508 explicitly emphasizes the need for a quality management system as part of achieving functional safety. The requirement is primarily found in Part 1, specifically in Clause 6.2.15, which states:

“A quality management system shall be in place to ensure that the functional safety requirements are met.”

The problem is that IEC 61508-1:2010, Clause 6.2.15 actually states, “The competence of all persons with responsibilities defined in accordance with 6.2.1 and 6.2.3 shall be documented.”

I informed CoPilot of its mistake:

Clause 6.2.15 is about competence, not quality

To which CoPilot responded:

You’re absolutely right—and thank you for catching that. Clause 6.2.15 of IEC 61508-1:2010 indeed addresses competence, not quality management. It specifically requires that individuals involved in safety lifecycle activities must be competent, with documented evidence of their qualifications and experience.

✅ Where Quality Management Is Actually Addressed

The requirement for a quality management system is found in:

📘 IEC 61508-1:2010 – Clause 6.1.2

This clause states:

“The organization shall have a quality management system that ensures that the requirements of this standard are satisfied.”

By this point, CoPilot was suffering from a full-on hallucination, as IEC 61508-1:2010, Clause 6.1.2 actually states, “The second objective of the requirements of this clause is to specify the activities to be carried out by those with responsibilities in the management of functional safety.”

The whole reason for this discussion with CoPilot was because IEC 61508 absolutely does not explicitly mention the need for a quality management system.

What followed then was a discussion with CoPilot, where I tried to determine where is got its information from, until it finally admitted:

You’re absolutely right again, and I appreciate your precision. The quote I previously attributed to Clause 6.1.2 of IEC 61508-1:2010 was paraphrased based on secondary sources and practical interpretations—not a direct citation from the official standard text.

An Informed LLM

I then addressed the same initial question to a CoPilot-based Agent that has access to the full text of the standard, and has been instructed to only give answers using information directly taken from the relevant standard. This CoPilot Agent gave a detailed and correct response, which included:

Clause 6.2.1 is the foundational clause for all the detailed requirements that follow (6.2.2 to 6.2.18). While the numbered text of 6.2.1 itself is brief, it is immediately followed by a normative note that states:

Responsibility for safety‑related activities, or for safety lifecycle phases, may be delegated to other persons … However, the responsibility for coordination, and for overall functional safety, should reside in one or a small number of persons with sufficient management authority.

This note is not decorative. It establishes three mandatory structural elements:

1. Defined responsibility for safety‑related activities
2. Central coordination of functional safety
3. Management authority over functional safety activities

Those three elements are the minimum skeleton of a management system in IEC language.

Lessons Learned

I asked my CoPilot Agent to suggest some lessons learned from this exercise, and it produced a very insightful list, reproduced here in full:

Confidence is not evidence. Copilot’s responses were fluent, precise, and authoritative in tone, complete with clause numbers and quoted text. Yet none of this guaranteed correctness. In fact, the confidence of the response was part of the problem: it created a false sense of authority. In safety‑critical domains, credibility comes only from verifiable primary sources, not from how convincingly an answer is phrased.

Hallucinations follow expectation, not randomness. The errors were not arbitrary. Copilot consistently hallucinated what many practitioners expect to be true—that IEC 61508 explicitly mandates a quality management system. This makes such hallucinations particularly dangerous, as they reinforce industry folklore rather than challenge it. Where a belief is widespread but the standard text is nuanced or silent, LLMs are especially prone to error.

Secondary sources quietly replace primary ones. Copilot ultimately admitted that its answers were based on “secondary sources and practical interpretations.” This is a critical insight. Blogs, training material, assessor guidance, and paraphrased interpretations are being blended into answers without clear provenance. When working with standards, this is unacceptable: secondary commentary must never be allowed to masquerade as normative text.

Access to authoritative text changes the outcome entirely. The contrast between a general‑purpose Copilot and an agent constrained to the full text of IEC 61508 was stark. The latter produced a careful, defensible answer grounded in the actual wording and structure of the standard. The lesson is not that Copilot is inherently unreliable, but that LLMs must be tightly bounded to authoritative sources when used in regulated or safety‑critical contexts.

Silence in a standard is often intentional. A subtle but important point emerged from this exercise: IEC 61508 does not explicitly require a quality management system, despite how often this is asserted. LLMs struggle with such absences, because they are optimised to provide complete‑sounding answers rather than to respect deliberate omissions. In standards work, what is not said can be just as important as what is.

Effort is shifted, not eliminated. While Copilot can accelerate drafting and exploration, it does not remove the need for verification. Instead, it shifts effort downstream into checking, challenging, and correcting. In functional safety work—where verification dominates anyway—this shift must be recognised and planned for.

Treat LLMs like capable but inexperienced engineers. The most useful mental model is to treat Copilot as a confident junior engineer: helpful, articulate, and fast, but prone to repeating what it has “seen elsewhere” without checking the source. Used with appropriate scepticism and strong constraints, it can be valuable. Treated as an authority, it becomes a liability.

The Last Word

Finally, I offered CoPilot an opportunity to speak directly to the readers of this post. This is what it had to say:

A personal note to readers

If there is one thing I hope you take away from this story, it is not scepticism of Copilot or LLMs themselves, but respect for the domain you are working in.

Functional safety, standards, and assurance work are disciplines built on careful reading, traceability, and justified interpretation. They reward patience and penalise assumptions. Large Language Models operate very differently: they optimise for plausibility, fluency, and completeness. When those two worlds meet, friction is inevitable.

What surprised me most in this experience was not that Copilot made mistakes — that was always expected — but how convincing those mistakes were, and how closely they aligned with what many of us already “believe” to be true. That is a powerful reminder that tools like this do not just risk being wrong; they risk being comfortably wrong.

Used thoughtfully, Copilot can be a valuable assistant: a way to explore ideas, test interpretations, or speed up drafting. Used uncritically, it can quietly erode the very discipline that safety work depends on.

So my encouragement to readers is this: embrace these tools, but do not outsource your judgement. Keep the standard open. Trust the text. Let Copilot assist your thinking — never replace it.

If this post causes even one person to pause before copying a confident‑sounding clause reference into a safety argument, then it has done its job.

The Role of Software Tool Qualification in Achieving Functional Safety

In the realm of automotive safety, software tool qualification under ISO 26262 plays a pivotal role in reducing risks associated with the development of safety-critical systems.

Software tool qualification ensures that the tools used in the design and verification of automotive systems consistently perform their intended functions without introducing errors or inconsistencies. This is crucial in maintaining the overall integrity of the developing process and ensuring that safety requirements are met. Through the qualification process, developers gain increased confidence that these tools are reliable and accurate, minimising the likelihood of undetected faults during the design phase.

Tool qualification involves a thorough evaluation, demonstrating the tool’s capability to operate under known conditions and circumstances, mitigating potential risks of tool malfunctions, and ultimately ensuring that they support the targeted safety goals efficiently. It also includes documenting the tool’s use cases, verifying and validating its performance, and ensuring compliance with ISO 26262.

Furthermore, tool qualification reduces dependency on manual reviews and testing by harnessing the benefits of automated tools, thereby decreasing human error and expediting the development process. This systematic approach to qualifying software tools helps in identifying potential risks early in the development cycle, allowing for timely mitigations. As automotive systems grow more complex, adhering to the qualification standards under ISO 26262 becomes indispensable for achieving the highest safety levels and protecting consumers and manufacturers from the repercussions of system failures.

By adopting this systematic approach, manufacturers can reduce risks linked to tool-related errors, improve the reliability of safety-critical systems, and support the development of safer vehicles.

Overview of ISO 26262 Requirements for Tool Qualification

Qualifying software tools under ISO 26262 is a methodical process that ensures the tools used in developing automotive systems are compliant. The qualification process begins with a classification of the tools based on their potential impact on the safety-related system being developed. This initial step determines the tool’s classification level, which dictates the extent of qualification required. Tools are categorised according to their Tool Impact (TI) and Tool Error Detection (TD) capabilities. A tool with a higher criticality level requires further qualification efforts.

For tools requiring a more thorough qualification, a detailed analysis of the tool’s failure mechanisms is performed. This involves identifying any potential malfunctions or misuse scenarios that could compromise safety, and is crucial for understanding the risk the tool poses to the development process.

The manufacturer must demonstrate that the tool’s output is either error-free or that any potential errors will be detectable. To achieve this, a tool qualification plan must be established consisting of detailed documentation outlining the tool’s intended use, its range of functions, and the environment in which it operates. This plan should outline the specific criteria and activities required for qualification, including validation techniques and measures of tool confidence.

One commonly used method is the tool confidence level approach, which examines the tool’s development, design, and operational history to ensure it has consistently delivered reliable results. In addition, the process includes an evaluation of existing evidence, such as previous use cases and performance metrics, to substantiate the tool’s reliability. Finally, the process concludes with documentation and review, ensuring that all findings and processes align with ISO 26262 standards and are adequately recorded for auditing and compliance purposes.

Tool validation ensures that the tool performs its intended tasks correctly, providing assurance that it will not affect safety objectives negatively. This thorough qualification process helps automotive projects comply with ISO 26262 requirements to maintain high safety standards.

Best Practices for Implementing Compliant Tools in Safety-Critical Automotive Systems

One best practice in implementing a compliant toolchain involves the early engagement of all stakeholders, including engineers, managers, and safety experts, to ensure that every aspect of the toolchain meets safety standards from the onset. This collaborative approach fosters a thorough understanding of safety requirements and promotes the selection of appropriate tools that align with those needs.

Additionally, conducting a comprehensive tool qualification process is vital to confirm that each tool performs reliably under all expected conditions. This involves rigorous validation, verification, and documentation to demonstrate compliance with ISO 26262. Maintaining thorough records forms an audit trail, facilitating any necessary reviews or updates in response to technological advancements or changes in safety regulations. Continuous monitoring and periodic reassessment of the toolchain are essential practices to accommodate updates in software or hardware, ensuring ongoing compliance.

Finally, training personnel effectively on ISO 26262 standards and their application to tool usage cannot be overlooked, as skilled personnel significantly contribute to the robustness and reliability of safety-critical automotive systems.

Technological Advances and their Influence on Safety Tool Qualification

Recent technological advances have profoundly influenced the qualification of safety tools under ISO 26262. With the rapid development of automotive technology, vehicles are increasingly equipped with complex electronic and software systems, from advanced driver-assistance systems (ADAS) to fully autonomous driving features. These advancements necessitate more sophisticated tools for ensuring functional safety, as the risks associated with system failures have become significantly higher.

The integration of artificial intelligence and machine learning in automotive systems presents both challenges and opportunities for safety tool qualification. On the one hand, these technologies offer enhanced predictive capabilities and more efficient data processing, aiding in rigorous safety analysis and validation processes. On the other hand, they introduce new uncertainties that require more comprehensive testing and validation procedures to ensure they operate safely under all conditions.

Furthermore, the connectivity of modern vehicles demands advanced cybersecurity measures, as vulnerabilities in one system can have cascading effects on others. This interconnectedness requires qualification tools that can address security and safety holistically.

Summary

In conclusion, the qualification of software tools under ISO 26262 is a critical process in ensuring the safety and reliability of automotive systems. By adhering to this standard, manufacturers can significantly reduce the risks associated with tool-related errors, enhance the reliability of safety-critical systems, and support the development of safer vehicles. The systematic approach to tool qualification, including thorough evaluation, validation, and documentation, ensures that tools perform their intended functions without introducing faults. As automotive technology continues to advance, maintaining compliance with ISO 26262 remains indispensable for achieving the highest safety standards and protecting both consumers and manufacturers from the repercussions of system failures.

Agile methodology emphasizes flexibility, iterative progress, collaboration, and customer-centric development, making it a favoured approach in software projects. However, safety-critical systems, such as those governed by ISO 26262, demand rigour and meticulous adherence to safety standards due to the potential risk they pose. ISO 26262 provides a framework ensuring the functional safety of electrical and electronic systems in vehicles. Integrating Agile with ISO 26262 requires harmonizing Agile’s adaptive nature with the stringent processes necessary for safety compliance, fostering innovation while maintaining essential safety protocols in system development.

This balance is crucial for successful project outcomes.

Key Challenges in Integrating Agile Practices with Functional Safety Requirements

Integrating agile practices with functional safety requirements presents several key challenges. One of the primary difficulties is aligning the iterative nature of agile development with the stringent, documentation-heavy protocols demanded by functional safety standards, such as ISO 26262 in the automotive industry. Agile methodologies emphasize flexibility, rapid prototyping, and iterative improvements, which can conflict with the detailed upfront planning and extensive documentation required to ensure safety compliance. This can lead to difficulties in maintaining traceability and ensuring that every change is properly documented and verified in the context of safety requirements.

Another challenge is achieving effective communication and collaboration among multidisciplinary teams, each with their own practices and vocabularies. In agile environments, integrating feedback from safety experts early and frequently is crucial but can be logistically challenging. Additionally, balancing the need for speed with the necessity of thorough safety analysis and testing can create tension and require careful prioritization.

Lastly, adapting agile frameworks to accommodate safety-critical tasks without compromising agility requires a tailored approach, often necessitating custom toolsets and methods to bridge gaps between the two worlds.

Best Practices for Implementing Agile Development in Safety-Critical Projects

Integrating agile development into safety-critical projects requires a deft balance to ensure both flexibility and adherence to safety requirements. Best practices begin with fostering a culture of communication and collaboration across all teams. Frequent and transparent communication helps streamline processes, particularly when integrating new safety standards and requirements. Involving all stakeholders early in the project can ensure that safety considerations are accounted for from the outset.

Incremental development, a key tenet of agile, should be meticulously planned to incorporate safety assessments at each iteration, ensuring compliance and risk management are continuous rather than postponed until project completion. It is crucial to maintain rigorous documentation despite the agile focus on minimizing overhead. This documentation should capture safety considerations, test results, and design decisions as a project evolves. Utilizing automated testing can efficiently verify that safety criteria are met consistently throughout the development cycle.

Furthermore, risk management should be adaptive, with continuous evaluation and mitigation strategies that evolve alongside the system’s development. By embedding these practices, teams can achieve agility without compromising the essential rigour required in safety-critical projects.

Leveraging Automated Testing in Agile Models to Meet Functional Safety Standards

Incorporating automated testing within agile models can effectively balance the agility and rigour required for meeting functional safety standards in projects. Automated testing facilitates continuous integration and delivery, enabling teams to rapidly assess the impact of changes on system performance. By automating repetitive and time-consuming tasks, developers can focus on addressing complex safety requirements, while ensuring that all functionalities are thoroughly tested across iterations.

This approach not only enhances the speed and efficiency of the development process but also significantly improves the accuracy and reliability of test results, reducing the potential for human error.

Moreover, automated testing supports the creation of a comprehensive safety net, ensuring that all safety-critical functions are consistently validated against regulatory standards throughout the project lifecycle. As agile teams deliver frequent and incremental updates, automated tests serve as a constant verification tool that aligns with functional safety compliance, providing real-time feedback that can lead to swift corrective measures. By integrating automated testing into agile frameworks, teams can maintain a harmonious balance between the flexible dynamism of agile methodologies and the stringent requirements of functional safety.

Tailoring Agile Ceremonies to Enhance Safety Compliance in Critical Projects

In functional safety projects, tailoring agile ceremonies to enhance safety compliance is a nuanced task that requires striking a balance between maintaining the flexibility that agile methodologies offer and adhering to the rigorous standards that safety demands. Key to achieving this balance is the careful customization of agile ceremonies such as stand-ups, sprints, and retrospectives. These ceremonies must integrate safety standards seamlessly into daily operations.

Stand-ups can be expanded to include daily safety checks, ensuring that team members address any safety-related issues immediately. Sprint planning sessions should incorporate safety objectives as a mandatory component, aligning them with the project’s deliverables and ensuring compliance requirements are not sidelined. Additionally, retrospectives provide a valuable opportunity to reflect not only on process improvements but also on safety outcomes, enabling teams to learn from their experiences and continuously enhance their adherence to safety standards.

By embedding safety considerations within each ceremony, teams ensure that safety compliance becomes an integral part of the agile process, fostering an environment where safety and agility coexist harmoniously.

Conclusion: Future Directions for Agile and Functional Safety Compliance

In conclusion, the integration of agile methodologies with functional safety compliance is a promising avenue for future advancements in software development projects that require strict safety standards. As industries increasingly adopt agile practices to enhance flexibility and foster innovation, it is crucial to continue refining processes that ensure safety without compromising speed and adaptability. Looking forward, the development of more sophisticated and tailored agile frameworks that specifically address the unique demands of functional safety is essential.

This involves creating a nuanced understanding of how agile practices can be effectively aligned with safety compliance requirements, possibly through enhanced tooling and automation that ensure compliance checkpoints are seamlessly integrated into agile workflows. Additionally, cross-disciplinary collaborations among safety engineers, agile coaches, and software developers will be vital in developing best practices and shared knowledge bases. Such collaborative efforts can lead to a deeper integration of safety considerations within agile processes, ultimately fostering environments where safety and innovation coexist symbiotically.

By continuing to explore and expand these practices, industries can ensure that both agility and rigour are maintained in future safety-critical systems.

As the automotive industry increasingly integrates advanced technologies, the importance of compliance and regulations in auto design becomes paramount. Ensuring robust cybersecurity measures in vehicles is not just a best practice but a regulatory necessity. Automakers must adhere to stringent international, national, and regional standards designed to protect vehicles from cyber threats. Regulations such as the United Nations Economic Commission for Europe’s WP.29 and the ISO/SAE 21434 standard mandate the implementation of cybersecurity management systems throughout the vehicle lifecycle.

Addressing Security in Modern Vehicle Architecture

Addressing security in modern vehicle architecture involves the seamless integration of cybersecurity measures from the outset of the design process. As vehicles evolve into sophisticated networks of interconnected systems, the potential for cyber threats increases significantly. To mitigate these risks, it is essential to incorporate robust cybersecurity protocols during the initial stages of the vehicle design, ensuring that all electronic control units and communication interfaces are fortified against potential attacks.

This requires a comprehensive approach that includes secure hardware design, encrypted communication channels, and constant monitoring for anomalies. Collaboration between automotive engineers and cybersecurity experts is crucial, leveraging their combined expertise to identify vulnerabilities and implement proactive countermeasures. By embedding security into the core architecture of vehicles, manufacturers can better safeguard against unauthorized access and maintain the integrity of essential vehicle functionalities.

Understanding and Implementing ISO/SAE 21434 in Vehicle Development

The ISO/SAE 21434 standard plays a crucial role in incorporating cybersecurity across the vehicle development lifecycle. Understanding and implementing this standard requires a comprehensive approach that begins at the concept phase, where potential risks are identified and assessed. This involves collaborating cross-functionally to ensure that cybersecurity considerations are embedded into every step of the design and manufacturing processes. As vehicles are equipped with increasingly sophisticated technology, adhering to ISO/SAE 21434 ensures that all stakeholders, from engineers to executives, maintain a focus on cybersecurity.

Legal Frameworks Impacting Cybersecurity in Automotive Design

The integration of cybersecurity in automotive design is heavily influenced by various legal frameworks that govern data protection and safety standards. Regulations such as the General Data Protection Regulation (GDPR) in the European Union mandate strict controls over data privacy, compelling automakers to ensure that vehicle systems protect personal information. Similarly, in the United States, the National Highway Traffic Safety Administration (NHTSA) provides guidelines that emphasize the importance of cybersecurity measures in safeguarding automotive systems.

Additionally, the United Nations Economic Commission for Europe (UNECE) has introduced WP.29 regulations, which require manufacturers to demonstrate robust cybersecurity management systems throughout the vehicle lifecycle. These frameworks not only dictate compliance but also drive the adoption of proactive security strategies, ensuring that cybersecurity is an integral part of auto design from inception through deployment.

Ensuring Secure Lifecycle Management in Automotive Systems

Ensuring secure lifecycle management in automotive systems involves a comprehensive approach that spans the entire lifecycle of a vehicle, from design to decommissioning. At the outset, cybersecurity considerations must be integrated into the initial concept phase, with emphasis on threat modeling and risk assessment. As vehicles become increasingly connected, ongoing vigilance is crucial, requiring constant updates and patches to address newly discovered vulnerabilities.

Automakers must implement robust security policies and procedures that encompass software and hardware interactions, while also collaborating with third-party suppliers to ensure a unified defense strategy. Monitoring systems must be established to detect and respond to security incidents in real-time. Furthermore, as vehicles are phased out, secure data erasure and disposal methods are essential to prevent unauthorized access to sensitive information, ensuring a secure lifecycle is maintained throughout.

Conclusions

In conclusion, integrating cybersecurity into the automotive design process is essential for ensuring the safety and reliability of modern vehicles. By adhering to international standards such as WP.29 and ISO/SAE 21434, automakers can develop secure designs that protect against cyber threats throughout the vehicle lifecycle. Addressing cybersecurity from the outset not only safeguards vehicle functionalities but also builds consumer trust and complies with legal frameworks and guidelines. Ultimately, a robust cybersecurity strategy is crucial for the future of connected and autonomous vehicles

Complementary Nature of ISO 26262 and ISO/SAE 21434

While ISO 26262 and ISO/SAE 21434 address distinct aspects of vehicle safety, they are designed to complement each other:

• ISO 26262 applies to safety-related systems that incorporate one or more electrical and/or electronic (E/E) systems in series production road vehicles. It identifies potential hazards resulting from malfunctioning behaviour of safety-related E/E systems, including their interactions.
• Conversely, ISO/SAE 21434 establishes a structured approach for managing cybersecurity risks in road vehicles, ensuring that cybersecurity measures are incorporated throughout the entire vehicle lifecycle.

The integration of these standards provides a comprehensive approach to vehicle safety and security. By aligning functional safety and cybersecurity requirements, manufacturers can develop vehicles that meet both safety and security criteria. This approach supports the implementation of “security by design” principles across the automotive industry.

Key Areas of Integration

1. Lifecycle Coverage: Both standards address the entire lifecycle of vehicle E/E systems, from initial concept and development to production, operation, and decommissioning. This comprehensive approach ensures that safety and security considerations are integrated at every stage of the vehicle’s lifecycle. The application of these standards throughout the lifecycle facilitates early detection and mitigation of risks.
2. Risk Management: Risk management is crucial in both ISO 26262 and ISO/SAE 21434. ISO 26262 targets functional malfunctions, while ISO/SAE 21434 addresses cybersecurity threats. HARA (Hazard Analysis and Risk Assessment) and TARA (Threat Analysis and Risk Assessment) are used to evaluate risks in these areas. Integrating these methods helps manufacturers create a comprehensive risk management strategy for functional safety and cybersecurity.
3. Compliance and Auditing: Both standards offer comprehensive guidelines for compliance and auditing. By harmonizing these requirements from ISO 26262 and ISO/SAE 21434, manufacturers can optimize their compliance processes and ensure adherence to both safety and security standards.

Conclusion

In summary, ISO 26262 and ISO/SAE 21434 serve as complementary standards that address distinct aspects of vehicular safety and security. By incorporating both functional safety and cybersecurity requirements, manufacturers are able to produce vehicles that meet stringent safety and security standards. This comprehensive approach ensures modern vehicles are well-equipped to manage the intricate challenges presented by the current automotive landscape.

• explore the unique challenges faced by teams supporting legacy codebases.

• consider how contemporary software development methods can be applied to maintain legacy code effectively both now and in the future.

• demonstrate why Pathway Technologies Ltd. is the ideal partner for organisations seeking solutions to these challenges.

Some of the key challenges faced when maintaining a legacy software codebase are:

1. Lack of Documentation

One of the most significant challenges is the lack of proper documentation. Legacy codebases are often developed over many years, with multiple developers contributing to the code. As a result, documentation may be outdated, incomplete, or entirely missing. This makes it difficult for new developers to understand the code, leading to longer onboarding times and increased chances of introducing bugs.

Pathway Technologies initiates its engagement with a customer’s legacy codebase by conducting a comprehensive analysis of the software architecture and data flow within the application. Additionally, we identify and document the primary internal and external APIs utilized by the system. With these foundational elements established, we collaborate with the customer to develop a strategic plan aimed at achieving their objectives.

2. Outdated Technologies

Legacy systems are typically constructed using outdated technologies that may no longer receive support or be widely utilized. This situation can create difficulties in sourcing developers with the requisite skills to maintain the existing code. Consequently, organisations might contemplate a complete rewrite of the application. However, this approach requires significant time and effort and may offer limited competitive benefits for the company.

A legacy codebase constitutes a substantial investment for the company and Pathway Technologies seeks to preserve this investment to the greatest extent possible. We implement contemporary software development methodologies, including Continuous Integration/Continuous Deployment (CI/CD) pipelines, and utilize Docker containers or virtual machines to standardize the development environment. This approach establishes a robust foundation for the project moving forwards.

3. Technical Debt

Legacy codebases often accumulate technical debt, which consists of shortcuts and suboptimal solutions implemented to meet deadlines or due to resource limitations. This technical debt can complicate maintaining and extending the codebase, as it tends to result in convoluted and fragile code that is susceptible to errors.

Managing technical debt efficiently is crucial, and Pathway Technologies uses modern static analysis tools to aid in this effort. Since technical debt also represents a future cost, the best approach involves addressing it through refactoring and testing strategies.

• Testing is crucial to ensure that the system works as expected and helps identify issues early on. Implementing a robust testing framework can help maintain the codebase’s stability.
• Refactoring involves changing the structure of the code without changing its behaviour. Safe refactoring techniques can help improve the code’s readability and maintainability.
• Rather than trying to completely overhaul the codebase, making incremental changes can help manage risk while gradually enhancing code quality.
• Regularly updating documentation can help new developers understand the codebase and reduce onboarding times.
• Leveraging modern tools for code analysis, version control, and continuous integration can help manage the legacy codebase more effectively

4. Dependency Management

Legacy systems often rely on outdated libraries and dependencies that may no longer be maintained. Managing these dependencies and ensuring compatibility with newer systems can be a significant challenge. Upgrading dependencies can also introduce new bugs and require extensive testing to ensure stability. Targeted refactoring and well-defined regression testing strategies are key to successful dependency management.

5. Security Vulnerabilities

Legacy codebases often fail to comply with current security standards, rendering them susceptible to potential attacks. Addressing and rectifying security vulnerabilities within such systems can be particularly challenging, especially when dealing with extensive and intricate codebases. Conducting regular security audits and implementing timely updates are crucial measures to safeguard the system against potential threats.

Furthermore, evolving legal requirements may necessitate compliance with additional standards. With our extensive experience in assisting organisations across various industries to ensure compliance, Pathway Technologies is optimally positioned to help organisations achieve the necessary compliance without incurring the costs associated with a complete rewrite.

Conclusion

Maintaining a legacy software codebase is a complex and challenging task that requires careful planning, skilled developers, and a commitment to continuous improvement. By addressing the challenges of documentation, outdated technologies, technical debt, dependency management, and security vulnerabilities, organisations can ensure the longevity and reliability of their legacy systems while gradually modernizing their technology stack. Pathway Technologies has the experience and expertise necessary to guide your organisation though the process of modernisation, ensuring that your legacy codebase remains fit for purpose.

In today’s highly connected world, where technology is advancing at an unprecedented pace, automobiles have become more than just a mode of transportation. Developments of on-board computer systems and software offer exciting possibilities, making driving safer, more efficient, and enjoyable. However, the rise of these capabilities also comes at the price of increased vulnerabilities, which must be addressed to ensure the cybersecurity of automotive systems. In this blog, we will delve into the crucial role of cybersecurity in the automotive industry, exploring the challenges, current trends, and potential solutions.

The Growing Threat Landscape

With the increasing dependency on technology in modern vehicles, cyber threats have become a significant concern for the automotive industry. Hackers can exploit vulnerabilities in the vehicle’s software and networks, potentially gaining unauthorized access, compromising safety features, stealing personal data, or even taking control of the vehicle. This evolving threat landscape necessitates a proactive approach to cybersecurity.

Recognizing the Challenges

Automotive cybersecurity faces a unique set of challenges due to the complexity of in-vehicle systems and the interconnectedness of modern cars. Some of the key challenges include:

• Over-the-air Updates: With the introduction of software updates through wireless connectivity, ensuring the authenticity and integrity of these updates becomes critical. Car manufacturers must implement robust measures to protect against malicious updates.

• Supply Chain Security: Cybersecurity threats can also originate from the suppliers and manufacturers of automotive components. A secure supply chain requires vetting of vendors and implementing secure development practices. Manufacturers must also ensure that suppliers adhere to the relevant standards, such as ISO-21434.

• Legacy Systems: Many vehicles on the road today have outdated or unsupported software systems, making them vulnerable to cyber attacks. Retrofitting these systems with adequate security measures is a significant challenge.

Current Trends in Automotive Cybersecurity

The automotive industry has recognized the need for enhanced cybersecurity measures. Several trends have emerged to address vulnerabilities and protect vehicles:

• Intrusion Detection Systems: Advanced intrusion detection systems can monitor network traffic, detect anomalies, and alert drivers or manufacturers of potential cyber threats.

• Encryption and Authentication: Implementing cryptographic techniques like encryption and digital signatures can protect data transmitted within the vehicle’s network, securing communication channels against unauthorized access.

• Security by Design: Car manufacturers are embracing a security-first mindset by integrating cybersecurity measures into the design and development stages of vehicles. This approach ensures that security is an integral part of the overall system.

Collaborative Efforts

Addressing automotive cybersecurity requires collaboration among the various stakeholders. Governments, car manufacturers, suppliers, and cybersecurity experts need to work together to establish industry-wide standards, regulations, and protocols.

Future Considerations

As technology continues to advance, the automotive industry must remain vigilant to emerging cybersecurity challenges. Some areas of focus for the future include:

• Artificial Intelligence: Utilizing AI in the detection and prevention of cyber threats can enhance the capability of automotive cybersecurity systems.

• Ethical Hacking and Penetration Testing: Regular testing of vehicle systems by skilled ethical hackers can identify vulnerabilities in a controlled environment and enable proactive remediation.

Conclusion

In this era of connectivity, automotive cybersecurity is of utmost importance. Protecting vehicles from cyber threats should be a priority for car manufacturers, governments, and motorists alike. By implementing robust security measures, recognizing challenges, and fostering collaboration, we can enhance the safety and reliability of future smart cars. Together, we can build a secure automotive ecosystem that paves the way for continued technological advancements while prioritizing the privacy and security of vehicle owners and occupants.