Expanded functional safety and security support enables comprehensive software verification across Renesas SoCs, MPUs and MCUs for applications in automotive, industrial, energy, medical and rail transportation.  

Wirral, UK—June 4, 2025—LDRA, the leader in automated software verification, traceability and standards compliance, today announced it has joined both the Renesas Ready Partner Network and the R-Car Consortium. This collaboration expands LDRA’s support to include system development using Renesas R-Car system on a chip (SoCs), microprocessors (MPUs) and microcontrollers (MCUs) that must comply with industry-wide functional safety and cybersecurity standards.  

“Joining the Renesas Ready Partner Network and R-Car Consortium enables us to work directly within the Renesas ecosystem to help development teams tackle real-world functional safety verification challenges,” said Ian Hennell, Operations Director, LDRA. “Our expanded collaboration ensures that every Renesas-based product team can evolve their software verification capabilities in line with their roadmaps for advanced driver assistance systems (ADAS), autonomous driving capabilities, software-defined vehicles (SDV) and connected car features.” 

Comprehensive software verification across the Renesas portfolio

The Renesas Ready Partner Network curates trusted technology partners that deliver commercial-grade building blocks that work out-of-the-box with Renesas products. With this announcement, the LDRA tool suite integrates with multiple Renesas IDEs (Integrated Development Environments) including e² studio and CS+, and supports the Renesas RZ family of MPUs and the RA, RX and RL78 families of MCUs through LDRA target license packages.  

This integration helps software development and verification teams quickly and efficiently comply with these functional safety and cybersecurity standards: 

• Automotive: ISO 26262 (up to ASIL D), ISO/SAE 21434, Automotive SPICE 

• Industrial and energy: IEC 61508, IEC 62443-4-1, IEC 60880, ISO 13849 

• Medical: IEC 62304 

• Rail transportation: EN 50128/EN 50716 

The automotive hardware platform consists of R-Car SoCs and RH850 MCUs designed to address diverse automotive applications, including automated driving, ADAS, connected gateways, in-vehicle infotainment, cockpit systems and dashboard implementations.  

With the LDRA tool suite supporting R-Car devices, embedded software teams can leverage proven verification capabilities directly within their existing development workflows. This integration enables developers to perform static analysis, dynamic testing and verification within a single platform that supports: 

• Target development on the R-Car S4 Starter Kit, RH850 Automotive MCU and other R-Car devices 

• The RoX (R-Car Open Access) Virtual Platform (VPF) to enable in-vehicle software development prior to hardware availability 

• Compliance with standards including ISO 26262, ISO/SAE 21434 and Automotive SPICE 

Accelerated development and compliance workflows

With the LDRA tool suite, development teams implement comprehensive software verification processes and techniques without extensive tool setup or platform-specific customization efforts. This streamlined approach proves particularly valuable for teams working on time-sensitive projects where functional safety compliance, security validation and reliable software operation are critical requirements.  

This integrated workflow supports verification activities from early development stages through to final compliance validation. In addition to Renesas toolchains and devices, the LDRA tool suite supports a wide range of technologies, including TASKING compilers and debuggers, Automotive Grade Linux, Green Hills Software INTEGRITY, QNX and AUTOSAR. 

“By integrating directly within the Renesas ecosystem, LDRA eliminates the traditional barriers that slow functional safety verification and security processes within their customers,” Hennell added. “Development teams can now implement comprehensive functional safety and security workflows from the first day of their projects, rather than spending weeks integrating disparate tools. This joint solution positions the entire automotive industry to deliver safer, more secure software at the pace required by modern vehicle development.” 

About LDRA

For 50 years, LDRA has developed and driven the market for software that automates code analysis and software testing for safety-, mission-, security- and business-critical markets. Working with clients to achieve early error identification and elimination and full compliance with industry standards, LDRA traces requirements through static and dynamic analysis to unit testing and verification for a wide variety of hardware and software platforms. The company was acquired by TASKING in 2025. 

Press release from our partner: Insyde® Software Supports AMD’s openSIL Framework for Client PCs

InsydeH2O® openSIL Integration Boosts Scalability and Platform Design Flexibility

TAIPEI, TAIWAN – May 22, 2025 – Insyde® Software, a leading provider of UEFI BIOS and OpenBMC-based systems management solutions, today announced that its InsydeH2O® UEFI BIOS now supports AMD’s open-source Silicon Initialization Library (openSIL) for AMD client platforms, expanding upon its established support for AMD’s server roadmap.

AMD openSIL is a modern, open-source framework designed to initialize system firmware on AMD platforms. Its host firmware-agnostic architecture and lightweight, modular interface provide platform developers with streamlined access to AMD silicon capabilities through exposed APIs, enabling greater control, flexibility, and scalability in system design.

InsydeH2O’s openSIL support delivers streamlined development, enhanced security, and accelerated time-to-market while optimizing the features of AMD’s latest client platforms.

“Our commitment to AMD’s openSIL initiative began on day one and we’re excited to extend this support today to client PCs,” said Aven Chuang, SVP at Insyde Software. “From InsydeH2O’s early server integration to our openDBG UEFI Debug Engine contribution with AMD at the 2024 OCP Summit, we’re enabling our mutual customers to build more agile, secure systems that fully leverage AMD’s architecture across diverse market segments,” added Chuang.

About Insyde Software
Insyde Software (www.insyde.com) is a leading worldwide provider of UEFI firmware, OpenBMC-based systems management solutions and custom engineering services for companies in the mobile, server, desktop and IoT (Internet-of-Things) computing industries. The company is publicly held (6231.TWO) and headquartered in Taipei, Taiwan with U.S. headquarters in Westborough, MA. The company’s customers include the world’s leading computing, communications and storage device designers and manufacturers.

Insyde and InsydeH2O are trademarks or registered trademarks of Insyde Software in the United States and other countries. AMD is a trademark or registered trademark of Advanced Micro Devices, Inc. Other names and brands may be claimed as the property of others.

Once embedded systems are deployed — whether in medical devices, vehicles, or industrial equipment — they often become a black box. What’s really happening during runtime? How can engineers detect anomalies before they result in downtime, safety risks, or non-compliance?

In this article, we explore why engineering runtime observability into embedded devices is no longer optional. We look at why traditional techniques like logging and watchdog timers fall short, and how modern observability methods help engineering teams shift from a reactive to a proactive approach.

Why Traditional Methods Are No Longer Enough

Logging is useful during development and debugging, but in production, logs are often too generic, limited in scope, or simply unavailable due to resource constraints. Watchdog timers can reset a system in case of a failure, but offer no visibility into the root cause.

In today’s landscape — where system safety, predictability, and regulatory compliance are paramount — that’s no longer sufficient.

What Modern Runtime Observability Looks Like

Modern runtime observability is about maintaining insight into system behavior even after deployment, without impacting performance or reliability. Examples include:

• Non-intrusive monitoring of CPU, memory, and I/O metrics

• Execution tracing and behavioral pattern detection

• Integration with edge/cloud observability platforms

• Standardized logging frameworks with ring buffers and intelligent triggers

This unlocks a shift from post-mortem analysis to predictive maintenance, anomaly prevention, and real-time system optimization.

Observability isn’t just about collecting data — it’s about engineering systems that explain themselves. — Gevorg Melikdjanjan, Account manager

Building Observability into the Architecture

Observability can’t just be an afterthought or bolt-on. It requires a design-first mindset:

• Identify which signals truly reflect system health and behavior

• Architect for separation between core logic and observability components

• Allow dynamic reconfiguration of observability parameters without recompiling

• Account for cybersecurity: observability should not introduce new attack surfaces

In many regulated industries — such as automotive, medical, and aerospace — these practices are not just beneficial, they’re necessary to meet standards like ISO 26262 or IEC 62304.

Transparency. Predictability. Trust.

At its core, runtime observability is about more than visibility — it’s about trust. Can your system behave transparently, predictably, and securely under all operating conditions?

By adopting a modern observability approach, engineering teams gain the ability to catch issues early, react faster, and continuously improve system performance and reliability — even in the most demanding real-world environments.

At Logic Technology, we provide the tools and expertise to help embedded teams architect observability into their systems from the ground up. From RTOS-aware analysis to secure data streaming from edge devices, we help you get visibility where it matters most. Curious how observability could be engineered into your embedded architecture? Let’s talk.

Leading smart meter manufacturers like Itron, Kamstrup and Growatt design their meters to last 20 years or more. But many start having operational issues within just seven years in the field. In the UK, for example, nearly four million smart meters didn’t work properly in 2024.

While hardware issues often take the blame, the real problem might lie somewhere less obvious: in your file systems and flash software controllers. In this article, we’ll shed light on a hidden threat to smart meter longevity and share practical solutions to help engineering teams extend their lifespan.

Why your smart meter longevity is at risk

Smart meters work around the clock—logging data, recording events, and updating firmware—with data and event logs typically being stored in SQLite databases. This constant activity puts a lot of pressure on NAND flash memory.

Most meters run on real-time operating systems (RTOS), with resource-constrained microcontroller units (MCUs) and limited memory. In this environment, flash storage becomes the weakest link. Factors like file system overhead, metadata updates, journaling, and garbage collection—moving valid data around to reclaim free space—all worsen the issue.

In an unoptimized system, these factors add up, causing flash memory to exceed its endurance limits sooner than expected. Many engineering teams overlook this risk, assuming default file systems are enough for smart meters. However, standard file systems are designed for general use, not the demanding endurance requirements of long-life embedded devices.

Smart meters are typically low-cost devices, often costing around 40 euros or less, so adding more flash memory might seem like an easy solution to extend lifespan. But this increases the bill of materials (BoM) and the hardware cost per device—something original equipment manufacturers (OEMs) can’t afford if they want to stay competitive in a cost-sensitive market.

The hidden threat: Write amplification in NAND Flash

Write amplification means a system writes more data than intended. For example, if your application writes 1KB of data, NAND flash memory could end up writing 8KB or more due to storage inefficiencies. The higher the write amplification, the faster the flash memory wears out—cutting device lifespan short.
Write amplification in smart meters causes premature wear on NAND flash memory, which can lead to data loss, unexpected failures, and costly replacements. This overlooked issue is dramatically shortening the life of smart meters across the industry.

Our recent SQLite workload tests show that write size, sync intervals, and concurrent processes significantly increase the write amplification factor (WAF). While longer intervals between syncs can help merge writes, they also raise the risk of data loss, which is a real problem for field devices like smart meters.

To dive deeper into these test results, check out our whitepaper How write amplification kills designs: steps to avoid early obsolescence.

So, the real challenge is: how can you solve the write amplification problem without increasing hardware costs or data loss?

The best approach: File systems & flash software controllers designed for longevity

Standard file systems aren’t designed for NAND flash, leading to excessive write amplification and premature wear. Flash-friendly file systems, however, significantly reduce this write amplification factor (WAF) and improve flash endurance.

Smart flash software controllers also make a difference. They manage how data gets written, erased, and redistributed across the memory. With better wear leveling and garbage collection, they prevent any single flash block from getting overworked, extending your device’s life and improving flash endurance in smart meters.
Power outages are inevitable for smart meters. When they happen, data corruption becomes a major risk. The right combination of file systems and flash software controllers provides robust protection, keeping your data intact and your operations stable.

A senior R&D manager at a leading smart meter company shared their experience with Tuxera Reliance Nitro™ file system and FlashFX Tera™ flash software controller: “We successfully completed lifespan testing, simulating over 20 years of product use with more than 1.2 billion SQLite3 write transactions.”

While their testing met the minimum lifespan requirement, our engineering team helped them optimize their system even further, extending the meter’s lifespan up to 32 years. This shows that even a small component like the file system can have a huge impact on overall device longevity.

Ensure a 20-year smart meter lifespan with smarter storage

To sum it up, you need to consider file systems and write amplification from the start to overcome smart meter longevity challenges.
By choosing the right embedded solutions for your smart meters, you can:
• Prevent early storage failures
• Reduce maintenance costs
• Meet regulatory requirements
For utility companies, this isn’t just a technical detail—it directly affects whether your meter readings are accurate and reliable, which impacts everything from billing to planning. Investing in optimized embedded file systems for smart meters today will save you from costly replacements down the road.