Accurate Technologies - BlogAccurate Technologies - Bloghttps://www.accuratetechnologies.com/blogTue, 31 Mar 2026 14:33:49 -0700http://zoho.com/sites/<![CDATA[Automotive Ethernet Explained Pt. 3]]>https://www.accuratetechnologies.com/blog/post/automotive-ethernet-explained-pt.-3

Automotive Ethernet Protocols in Practice: From SOME/IP to ADAS Data Streams

Automotive Ethernet provides the bandwidth modern vehicles need. But bandwidth alone does not solve the communication challenges inside a vehicle. 

Once Ethernet became part of the vehicle architecture, the industry needed protocols designed specifically for automotive systems. These protocols define how services are discovered, how diagnostics operate, and how large data streams move between ECUs. 

Three of the most common are SOME/IP, DoIP, and AVB/TSN. Each solves a different problem in the vehicle network. 

Why Automotive Ethernet Protocols Exist

Traditional automotive networks like CAN are message-based. Every ECU knows exactly which message IDs to listen for. 

Ethernet networks operate differently. They are packet-based, and communication is typically organized around services and endpoints rather than fixed message IDs. 

  • Modern vehicles also require capabilities that earlier networks were never designed to support, including: 
  • High-bandwidth sensor data 
  • Service-oriented software architectures 
  • Large-scale diagnostics and software updates 
  • Precise timing and synchronization 

Automotive Ethernet protocols address these needs while maintaining the reliability required for vehicle systems. 

SOME/IP: Service-Oriented Communication

SOME/IP (Scalable Service-Oriented Middleware over IP) is one of the most widely used protocols on Automotive Ethernet networks due to it’s compatibility with AUTOSAR standards. 

Instead of fixed messages, SOME/IP allows ECUs to offer services. Other ECUs can discover and request those services dynamically. 

For example: 

  • A camera ECU may offer a video processing service 
  • A domain controller may offer vehicle state information 
  • An ADAS system may request sensor data from multiple sources 

SOME/IP enables this type of communication through: 
  • Service discovery 
  • Request and response messaging 
  • Event notifications 

This architecture supports the move toward software-defined vehicles, where software components interact more like distributed applications than isolated ECUs. 

DoIP: Diagnostics Over Ethernet

Diagnostics have traditionally run over CAN using UDS (Unified Diagnostic Services). 

As Ethernet networks became common in vehicles, the industry introduced Diagnostics over IP (DoIP) to carry diagnostic messages over Ethernet. 

DoIP allows engineers and service tools to: 

  • Access ECUs over Ethernet 
  • Perform diagnostics more quickly 
  • Transfer large data sets efficiently 
  • Support faster software updates 

Because Ethernet supports significantly higher bandwidth than CAN, operations like flashing firmware or retrieving large diagnostic logs can be completed much faster. 

In mixed-network vehicles, gateways often route diagnostics between CAN-based ECUs and Ethernet-based ECUs so diagnostic tools can communicate across the entire vehicle. 

AVB and TSN: Managing Time-Sensitive Data

High-bandwidth data streams introduce another challenge: timing. 

ADAS systems often depend on synchronized data from multiple sensors. Cameras, radar, and lidar must deliver data with predictable timing so the vehicle can build an accurate model of its surroundings. 

This is where AVB (Audio Video Bridging) and TSN (Time-Sensitive Networking) come into play. 

These technologies extend Ethernet with capabilities that support: 

  • Time synchronization across ECUs 
  • Guaranteed bandwidth allocation 
  • Predictable latency 
  • Deterministic communication 

TSN, in particular, is becoming increasingly important as vehicles rely more heavily on synchronized sensor data. 

ADAS Systems Drive the Need for Bandwidth

ADAS and automated driving systems generate enormous amounts of data. 

Consider a modern vehicle equipped with multiple cameras, radar sensors, and other perception systems. Each sensor produces continuous streams of information that must be processed, combined, and analyzed in real time. 

These systems require: 

  • High bandwidth 
  • Reliable data delivery 
  • Precise synchronization 

Automotive Ethernet provides the physical network for this data, while protocols like SOME/IP and TSN help ensure the data moves efficiently and arrives when it is needed. 

Without these protocols, managing this level of communication would be extremely difficult. 

How Data Flows Between ECUs

In a modern Ethernet-enabled vehicle, data often flows through multiple layers of the network. 

A simplified example might look like this: 

    1. Sensors capture raw data such as camera frames or radar measurements. 
    2. Sensor ECUs transmit data over Automotive Ethernet. 
    3. Domain or zonal controllers aggregate and process information from multiple sensors. 
    4. Processed data is shared with other vehicle systems through service-based communication such as SOME/IP. 
    5. Diagnostic and maintenance functions operate over DoIP when needed. 

This architecture allows high-bandwidth data to move efficiently between key computing nodes while maintaining compatibility with other vehicle networks such as CAN and LIN. 

Up Next

Understanding the protocols is only part of the picture. The way vehicles are architected around these networks is evolving as well. 

In the next post, we will explore zonal architectures and how Automotive Ethernet is reshaping vehicle network design. 
]]>Tue, 31 Mar 2026 14:25:42 -0400<![CDATA[Automotive Ethernet Explained Pt. 2]]>https://www.accuratetechnologies.com/blog/post/automotive-ethernet-explained-pt.-2

CAN, CAN FD, and Automotive Ethernet: 
​When to Use Each and How They Coexist

Automotive Ethernet did not replace CAN. It expanded what vehicle networks can handle. 
Modern vehicles do not run on a single network technology. Instead, they use a combination of LIN, Classic CAN, CAN FD, and Automotive Ethernet. Each has strengths. Each has limits. Understanding when to use each one is essential for system design, integration, and validation. 

The Strengths of LIN

LIN is a single wire communication network. Best suited for small low bandwidth networks where precise real time control is not required 

Where LIN excels: 

  • HMI interface controls such as turn signal and power seat controls.  

  • Actuators that control seats, windows, HVAC systems and others. 

  • Lighting systems 

  • Alternator control 

LIN is limited by both speed and data payload size. Even with these limitations it works well in communication with non-critical systems 

Where LIN struggles: 

  • Slow, 20Kbps max 

  • Lack of message arbitration requires a Commander/Responder network 

  • Limited message ID range  

When bandwidth requirements increase, the next step is moving up to a CAN network. 

The Strengths of Classic CAN

Classic CAN was built for reliable, deterministic control communication. It remains one of the most efficient ways to move small, time-critical messages between ECUs. 

Where CAN excels: 

  • Powertrain control 

  • Chassis systems 

  • Body electronics 

  • Safety-critical signaling 

  • Peer to Peer communications make the network architecture simple. 

While Classic CAN has a maximum bit rate of 1 Mbps, it typically runs at 500 Kbps or less. That is more than sufficient for control messages that are only a few bytes long. 

Where CAN struggles: 

  • Large data payloads 

  • High-resolution sensor data 

  • Software updates 

  • Aggregating multiple high-data-rate systems 

When bandwidth requirements increase, adding more CAN buses increases wiring, gateways, and architectural complexity. 

What CAN FD Improves

CAN FD was introduced to extend the life of CAN. The migration from Classic CAN to CAN FD is low cost and low effort because the network topology is the same as Classic CAN. 

It increases: 

  • Data rate during the data phase 

  • Maximum payload size per frame 

CAN FD can operate at higher data rates than classic CAN and supports payloads up to 64 bytes per frame. This provides several benefits. 

  • Significantly reduces time of ECU flashing operations. 

  • Larger message payload reduces message traffic providing improving data throughput for diagnostic and calibration activities. 

However, CAN FD still operates in the megabit range. It improves efficiency but does not fundamentally solve high-bandwidth demands such as camera streams or centralized compute data flows. 

Where Automotive Ethernet Becomes Necessary

When systems require tens or hundreds of megabits per second, CAN and CAN FD are no longer practical. 

Automotive Ethernet is required for: 

  • ADAS camera data 

  • Radar and lidar aggregation 

  • Infotainment backbones 

  • Centralized domain or zonal controllers 

  • High-speed data logging 

  • Diagnostics over IP 

With standards such as 100BASE-T1 and 1000BASE-T1, Ethernet provides the bandwidth needed for data-heavy systems while maintaining predictable performance through switched architectures. 

It is not about replacing CAN. It is about enabling what CAN was never designed to carry

Mixed-Network Vehicle Architectures

Modern vehicles can combine all of these technologies to optimize cost and vehicle complexity. 

A simplified example looks like this: 

  • LIN handles low speed HMI and actuator functions. 

  • CAN/CAN FD are used for distributed control systems. 

  • Automotive Ethernet acts as a high-bandwidth backbone between domain or zonal controllers. 

Instead of dozens of isolated networks, Ethernet often connects higher-level controllers, while CAN remains close to edge devices such as sensors and actuators. 

This layered approach keeps control communication simple and deterministic while allowing data-intensive systems to scale. 

The Role of Gateways

Gateways are the bridge between networks. 

What they do: 

  • Translate messages between CAN, CAN FD, and Ethernet 

  • Manage diagnostics across multiple networks 

  • Enforce security and filtering rules 

  • Control traffic flow between domains 

  • Provide the needed Ethernet Switch functionality needed for Automotive Ethernet connectivity. 

In mixed-network vehicles, gateways become critical integration points. Misconfiguration, timing mismatches, message mapping errors, or diagnostic routing issues often surface here first. 

As Ethernet adoption increases, gateway complexity also increases. Engineers must understand both message-based CAN communication and packet-based Ethernet communication to debug effectively. 

In development and validation environments, dedicated vehicle communication gateways are often used to simulate or manage traffic between CAN and Automotive Ethernet networks before full vehicle integration. These platforms allow teams to validate message translation, diagnostic routing, and network behavior under controlled conditions. 

For example, development-grade solutions such as Accurate Technologies’ Vehicle Communication Gateway (VCG) can be used to bridge CAN, CAN FD, and Automotive Ethernet during bench testing. This allows engineers to verify coexistence scenarios and gateway behavior early in the development cycle, reducing risk later in vehicle-level validation. 

Choosing the Right Network

A useful way to think about it: 

  • If the system is very low bandwidth with limited nodes, LIN is ideal. 

  • If the system is control-heavy and low bandwidth, CAN is ideal. 

  • If more efficiency and larger payloads are required, CAN FD is appropriate. 

  • If the system moves large volumes of data or connects high-level controllers, Automotive Ethernet is necessary. 

Most modern vehicles use all three. 

The goal is not to pick one winner. The goal is to architect them correctly together. 

Why This Matters for Development and Validation

As vehicles adopt mixed-network architectures, engineering challenges shift: 

  • Debugging requires visibility across multiple network types. 

  • Gateway behavior becomes a critical validation point. 

  • Diagnostics must work seamlessly across CAN and Ethernet. 

  • Timing and bandwidth constraints must be validated at the system level. 

Understanding how these networks coexist is essential for building and validating reliable vehicle architectures. 

Up Next

Now that we have covered how LIN, CAN, CAN FD, and Automotive Ethernet work together, the next step is understanding what runs on top of Ethernet. 
In Blog #3, we will explore Automotive Ethernet protocols in practice, including SOME/IP, DoIP, and how ADAS data actually moves through the vehicle. 

]]>Fri, 06 Mar 2026 10:54:59 -0500<![CDATA[Automotive Ethernet Explained Pt. 1]]>https://www.accuratetechnologies.com/blog/post/automotive-ethernet-explainedPT1

Why the Industry Moved Beyond CAN-Only Networks and What Makes It Different

For decades, CAN bus has been the backbone of in-vehicle communication. It is reliable, deterministic, and well suited for control-heavy systems like powertrain, chassis, and body electronics. 

So why did the automotive industry introduce Automotive Ethernet? 

The answer comes down to scale. Modern vehicles outgrew what CAN-only architectures can realistically support. Understanding why Ethernet was needed, why regular Ethernet was not well suited, and how Automotive Ethernet fits alongside existing networks is key to understanding modern vehicle design. 

Why CAN-Only Networks Hit Their Limits

CAN was designed for reliable message-based communication between embedded controllers. For many years, bandwidth demands were low and predictable. That changed quickly. 

Modern vehicles now include: 
    • Multiple cameras and high-resolution displays 
    • Radar, lidar, and sensor fusion systems 
    • Centralized compute and software-defined features 

Even with CAN FD, bandwidth is still measured in kilobits to a few megabits per second due to limited data packet sizes. That is more than enough for control signals, but not nearly enough for data-heavy systems like ADAS or infotainment. 
As vehicle complexity increased, OEMs faced a choice: 
    • Add more CAN buses and gateways, which increases cost and complexity 
    • Introduce a high-bandwidth backbone network 
Automotive Ethernet became that backbone. 

Moving to Ethernet

While Ethernet can provide significantly higher bandwidth over CAN FD, it is not a drop-in replacement: 
    • Ethernet is intended to be Point to Point requiring switches when there are more than two nodes. 
    • Much of the available Ethernet hardware was not suited for the temperature ranges needed for the automotive industry. 
    • Typical Ethernet uses 2 or 4 twisted pairs that increases cost and wiring complexity. 
    • Significantly different implementations in software make Ethernet a much larger change than the migration from CAN to CAN FD. 
While Ethernet provided a clean way to move large data streams there were costs and other technical details that needed to be addressed.

What Makes Automotive Ethernet Different from Regular Ethernet

At first glance, Ethernet looks the same everywhere. Vehicles, however, are a very different environment from offices or data centers. 
Automotive Ethernet is specifically engineered for in-vehicle use. 

Single-Pair Ethernet

The single biggest difference is that Automotive Ethernet uses a single twisted pair putting it on par with the 2 wires used for CAN. 

    • Reduced cable weight 
    • Lower cost 
    • Easier routing through the vehicle 
Standards like 100BASE-T1 and 1000BASE-T1 are designed specifically for automotive applications. 

Automotive-Grade Physical Layers

Automotive Ethernet PHYs are built to survive: 

    • Wide temperature ranges 
    • Constant vibration and shock 
    • High levels of electrical noise and EMI 
This is why regular Ethernet adapters and switches cannot simply be plugged into a vehicle network. 

Determinism by Design

A common misconception is that Ethernet is not deterministic. 

In automotive systems, determinism is achieved through: 

    • Full-duplex point-to-point links 
    • Switched network architectures 
    • Time-sensitive networking where required 
The result is predictable latency suitable for high-bandwidth and time-aware systems. 

Vehicle-Specific Protocols on Top

Automotive Ethernet is not just about moving packets faster. It supports vehicle-specific communication through protocols such as: 

    • SOME/IP for service-oriented communication 
    • DoIP for diagnostics over IP 
    • AVB and TSN for synchronized data streams 
These protocols are a major reason Automotive Ethernet behaves very differently from traditional IT Ethernet. 

Automotive Ethernet Complements CAN

Automotive Ethernet does not replace CAN as it has proven reliability and is extremely cost effective. 
In real vehicles: 

    • CAN and CAN FD handle control and safety-critical communication 
    • Automotive Ethernet handles data-heavy systems and network backbones 
    • Gateways connect CAN and Ethernet domains 
This coexistence allows OEMs to scale vehicle capabilities without abandoning proven technologies. 

Why This Matters for Development and Testing

As Automotive Ethernet becomes more common, engineering challenges change: 

    • Network bring-up and configuration become more complex 
    • Latency and packet loss must be measured and understood 
    • Diagnostics span multiple network types 
    • Tools must understand automotive protocols, not just raw Ethernet frames 

What Comes Next

With the fundamentals in place, the next question is practical: 
When should CAN, CAN FD, or Automotive Ethernet be used, and how do they work together in real vehicles? 
That is the focus of Blog #2 in this series. 

Automotive Ethernet vs.Regular Ethernet
]]>Wed, 18 Feb 2026 08:29:22 -0500<![CDATA[CAN Silent Mode ]]>https://www.accuratetechnologies.com/blog/post/CAN-Silent-Mode

A Quiet but Critical Tool for CAN Development

When developing, testing, or validating CAN bus–based systems, engineers often need visibility into network traffic without influencing the behavior of the system itself. This is where Silent Mode can play an essential role. Silent mode allows engineers to observe, analyze, and validate CAN communication passively without transmitting acknowledgements or frames onto the bus. 

In this blog, we’ll explain what silent mode is, why it matters during development, and how tools from ATI support professional CAN workflows using this capability. 

What Is Silent Mode on a CAN Device?

In a standard CAN network, every active node participates fully in communication.
This includes: 

  • Transmitting messages 

  • Acknowledging (ACK) received frames 

  • Influencing bus load and arbitration 

A CAN interface operating in Silent Mode (sometimes called listen-only mode) disables transmission and ACK behavior.
The device: 

  • Listens to all CAN traffic 

  • Decodes frames in real time 

  • Does not acknowledge messages 

  • Cannot affect arbitration, error handling, or bus timing 

From the network’s perspective, the silent node is effectively invisible.

Why Silent Mode Matters in Development

1. Non-Intrusive Debugging 

During early development or troubleshooting, the last thing an engineer wants is for a diagnostic tool to alter system behavior. Silent mode enables: 

  • Safe connection to production ECUs 

  • Monitoring safety-critical networks 

  • Debugging issues that only occur under real-world conditions 

Because the tool never transmits, it cannot mask wiring faults, timing issues, or missing nodes. 

Shape 

2. Verifying Network Health and Topology 

Silent CAN devices are commonly used to: 

  • Confirm that all expected messages are present 

  • Measure bus load and message frequency 

  • Detect unexpected traffic or rogue nodes 

With ATI CAN interfaces, engineers can use CANLab to connect onto an existing vehicle or industrial network and immediately begin capturing traffic without influencing the system under test. 

Shape 

3. Supporting Compliance and Validation 

In regulated industries such as automotive, off-highway, and industrial automation, validation teams must often prove that: 

  • A system behaves correctly under defined conditions 

  • Diagnostic tools did not influence test results 

Using silent mode provides a clear audit trail showing that the measurement setup was passive. ATI tools configured in silent mode are frequently used during: 

  • Acceptance testing 

  • Field data collection 

  • Customer-site troubleshooting 

Shape 

4. Parallel Development and Reverse Engineering 

Silent mode is especially valuable when working with third-party or legacy systems where documentation may be incomplete. Engineers can: 

  • Observe message IDs and payloads 

  • Correlate signals to system behavior 

  • Build databases without risk of interference 

For example, an ATI CANLab interface can be connected in silent mode while engineers map traffic before enabling active simulation or message injection later in the development cycle. 

Silent Mode in ATI CAN Tools

ATI designs its CAN interfaces and CANLab software with development-first workflows in mind. Silent mode support is a core feature across their professional toolchain. 

Key Benefits in ATI Products 

  • Hardware-level silent configuration to ensure zero bus impact 

  • Seamless CANLab integration for logging, filtering, and decoding 

  • Rapid switching between silent monitoring and active participation 

  • Enterprise-ready reliability for lab, vehicle, and field use 

This allows a single ATI interface to support the full lifecycle from passive observation to active testing without changing hardware. 

When to Use Silent Mode vs Active Mode

Scenario 

Recommended Mode 

Initial network discovery 

Silent Mode 

Field data logging 

Silent Mode 

Safety-critical system observation 

Silent Mode 

ECU simulation or testing 

Active Mode 

Fault injection 

Active Mode 

A common best practice is to start silent, then go active once the system is understood. 

Conclusion

Silent Mode CAN devices may not transmit a single bit onto the bus but their value during development is significant. By enabling truly non-intrusive observation, they protect system integrity while giving engineers the insight they need to design, debug, and validate complex CAN networks. 

With tools from ATI, silent mode is not an afterthought it’s a foundational capability that supports professional-grade CAN development from first connection to final validation. 

]]>Thu, 29 Jan 2026 11:04:00 -0500<![CDATA[9. From Hobbyist to Pro: Choosing the Right CAN Tooling ]]>https://www.accuratetechnologies.com/blog/post/pt.-9-introduction-to-canbus

For many engineers, an introduction to CAN bus begins with a simple setup: a microcontroller, a low-cost CAN controller, and a few examples. This approach is affordable, accessible, and effective for learning the fundamentals of CAN communication; frames, identifiers, bit rates, and basic message handling. 

As projects mature, however, these early tools often struggle to keep up with real-world demands. 

In this post, we’ll explore when it makes sense to move beyond hobbyist CAN tools, what differentiates professional CAN solutions, and how ATI CAN interfaces paired with CANLab provide a practical path into professional-grade CAN development. 

When DIY CAN Tools Reach Their Limits

Low-cost CAN setups are ideal for experimentation, but they are rarely designed for sustained engineering work. Common limitations include: 

Inconsistent behavior under higher bus load 

    • Limited or inaccurate timestamping 
    • Minimal error detection and diagnostics 
    • Fragile custom scripts for decoding 
    • Lack of long-duration logging and replay 
    • No formal support or validation 

These challenges become critical when CAN moves from a learning exercise to a system dependency; such as during debugging, validation, reverse engineering, or customer-facing development. 

What Changes at the Professional Level

Professional CAN tools are designed with reliability, observability, and repeatability in mind. Rather than focusing solely on basic frame transmission and reception, they emphasize: 

    • Stable, electrically robust CAN interfaces 
    • Precise, hardware-based timestamps 
    • High-performance capture and logging 
    • Advanced filtering and triggering 
    • Consistent behavior across systems and users 
The goal is not just to “see traffic,” but to understand system behavior with confidence. 

ATI CAN Interfaces: Built for Engineering Work

ATI CAN interfaces are designed for engineers who need dependable hardware that works consistently across long development cycles. 
    They provide: 

    • Reliable USB-to-CAN connectivity 
    • Clean electrical performance suitable for real networks 
    • Drivers intended for sustained use, not just demos 
    • Hardware capable of handling continuous monitoring and logging 
This makes them a solid foundation for professional CAN analysis, testing, and development. 

CANLab: Professional Capability Without Unnecessary Complexity

CANLab complements ATI hardware by focusing on the workflows engineers use most often. 
    Key capabilities include: 

    • Live visualization of CAN traffic 
    • High-speed logging for offline analysis 
    • Flexible filtering and triggering 
    • Message and signal-level decoding 
    • J1939 SPN decoding support 
    • Capture and replay for debugging and validation 
Rather than attempting to cover every possible CAN-related standard, CANLab prioritizes clarity, usability, and performance, making it approachable for engineers upgrading from DIY tools while still meeting professional expectations. 

Scalable Features and Practical Licensing

Not every project needs the same level of tooling. CANLab is offered in multiple variants, allowing teams to: 

    • Start with essential monitoring and logging 
    • Add advanced analysis features as requirements grow 
    • Align tool capabilities with project scope and budget 
This scalable approach helps avoid both underpowered setups and over-engineered solutions. 

Supporting Real Engineering Workflows

Professional CAN tooling must integrate smoothly into broader engineering environments. CANLab and ATI tools are designed to support: 

    • Repeatable testing and validation 
    • Clear data capture for collaboration and reporting 
    • Long-term use across development, Quality Assurance (QA), and support teams 
    • Vendor-backed support when issues arise 
These considerations become increasingly important as CAN-based systems move closer to production and deployment. 

From Learning Tool to Engineering Instrument

Transitioning from hobbyist CAN tools to professional solutions isn’t about discarding what you’ve learned, it’s about building on it. 

If early CAN setups helped you understand how CAN works, professional tools like ATI CAN interfaces and CANLab help you understand why systems behave the way they do, and give you the confidence to act on that understanding. 

At this stage, tooling stops being a constraint and becomes a critical part of successful CAN-based engineering. 

Learn More
]]>Fri, 09 Jan 2026 11:04:28 -0500<![CDATA[8. Higher-Layer Protocols: CANopen, J1939, and UDS ]]>https://www.accuratetechnologies.com/blog/post/pt.-8-introduction-to-can-bus

Understanding Structured Data and Application-Layer Standards on CAN Bus

As we’ve seen throughout this series, a CAN frame is intentionally simple: 11 or 29 bits of identifier, data  payload. This minimalism makes CAN fast, deterministic, and flexible—but it also means that different industries needed ways to define what those bytes represent.

This is where higher-layer protocols come in. They standardize data structures, communication flows, and device behaviors on top of the basic CAN transport. Whether you're working on heavy-duty vehicles, industrial automation, robotics, or medical equipment, chances are you're interacting with one of these application-layer standards. 

In this post, we’ll explore three of the most widely used: CANopen, SAE J1939, and UDS (Unified Diagnostic Services)—what they solve, how they structure data, and where you’re likely to encounter them. 

CANopen: Modular Control for Industrial and Robotics Systems

Originally defined by CAN in Automation (CiA), CANopen is popular in automation, robotics, and medical devices where multiple intelligent nodes must coordinate. 

Why CANopen Exists

CANopen provides: 
  • A standardized Object Dictionary for device parameters 
  • Real-time messaging for control loops 
  • A predictable set of device behaviors (profiles for drives, sensors, I/O modules)

Key Concepts

  • PDOs (Process Data Objects)
    Real-time data messages—position, velocity, force, sensor values—sent without request. 
  • SDOs (Service Data Objects)
    Request/response messages for configuration and parameter access. 
  • NMT (Network Management)
    Controlling device states (pre-operational, operational, reset). 
CANopen Protocol Stack

Typical Use Cases

  • Servo drives in robotics 
  • Infusion pumps and imaging systems 
  • Modular I/O in factories 

How Tools Like CANLab Fit In

Even without a full protocol stack, being able to capture traffic, decode identifiers, and interpret payloads using dictionaries or EDS files helps engineers inspect PDOs and monitor device interactions. 

SAE J1939: Structured Messaging for Heavy-Duty Vehicles

J1939 is built around 29-bit identifiers and a standardized way of grouping signals. It’s the backbone of communication in agriculture, trucking, construction, and marine applications. 

Why J1939 Exists

Heavy-duty environments must ensure that ECUs from multiple vendors can cooperate—engine, transmission, brakes, telematics, hydraulic controllers, etc. 

Key Concepts 
  • PGNs (Parameter Group Numbers)
    Message “types” defined by the identifier. 
  • SPNs (Suspect Parameter Numbers)
    Named, scaled signals within a PGN—engine speed, fuel rate, boost pressure. 
This structured approach means engineers can decode data consistently as long as they know the PGN and SPN definitions. 

Typical Use Cases 

  • Engine and emissions monitoring 
  • Tractor implement communication 
  • Fleet telematics and diagnostics 
  • Hydraulic equipment control 

How Tools Like CANLab Fit In

Tools can decode PGNs or SPNs from raw CAN frames when given the definitions, making it easier to validate equipment behavior or inspect network traffic during testing. 

UDS (Unified Diagnostic Services): The Standard Diagnostic Protocol

UDS (ISO 14229) is the diagnostic framework used in modern passenger cars, many commercial vehicles, and increasingly in specialized equipment. 

Why UDS Exists

Manufacturers needed a unified system to: 

  • Read diagnostic trouble codes (DTCs) 
  • Request data 
  • Perform ECU programming 
  • Control routines and tests 

Key Concepts

  • Service IDs (SIDs)
    Each UDS operation corresponds to a numeric command (e.g., 0x22 for Read Data By Identifier). 
  • DIDs (Data Identifiers)
    Structured identifiers for parameters—VIN, temperature sensors, calibration values. 
  • Security Levels
    Seed/key mechanisms for unlocking sensitive functions. 

Typical Use Cases

  • Dealer-level diagnostics 
  • Field service for specialized machinery 
  • ECU flashing and reprogramming 
  • Advanced testing and validation 

How Tools Like CANLab Fit In

Even without UDS automation, engineers can observe and analyze diagnostic exchanges directly on the CAN network, which is valuable during integration and troubleshooting. While UDS has a well-defined command/response structure, the in-vehicle implementation can be very OEM specific. The integrated scripting available in CANLab can be used to create custom UDS command sequences. 

Where These Protocols Are Used

Heavy-Duty & Off-Highway 

  • J1939 for engine, transmission, and vehicle systems 
  • UDS for diagnostics and firmware updates 
  • CANopen for implement controls (ISO 11783 based on J1939/CANopen concepts) 

Medical Devices 
  • CANopen in pumps, imaging, patient monitoring 
  • UDS occasionally for maintenance diagnostics 
  • Emphasis on deterministic control and safe parameter access 

Robotics & Automation 
  • CANopen for drives and real-time control 
  • Custom higher-layer protocols for proprietary robots 
  • UDS in some robotic platforms for service diagnostics

Conclusion: Higher-Layer Protocols Bring Meaning to CAN

Higher-layer protocols such as CANopen, J1939, and UDS give structure and meaning to raw CAN traffic, enabling interoperability across industries from heavy-duty vehicles to robotics and medical systems. Understanding how these protocols package data; whether through PGNs, SPNs, PDOs, or diagnostic services, helps engineers work more confidently across diverse applications. 

In our next article, we’ll shift focus from protocols to practice by exploring how engineers choose the right CAN tools as they move from hobby-level experimentation to professional workflows. 

]]>Mon, 15 Dec 2025 12:42:33 -0500<![CDATA[Pt. 7 Introduction to CAN Bus]]>https://www.accuratetechnologies.com/blog/post/pt.-7-introduction-to-can-bus

Logging, Analyzing, and Replaying CAN Data

Record and Playback with CANLab

In our previous post, Sniffing a Vehicle’s OBD-II Network, we explored how to safely and effectively monitor live CAN traffic from production vehicles using ATI hardware and CANLab. That hands-on introduction focused on passive data collection—observing ECU communication without altering system behavior. 

Now we take the next step: moving from observation to interaction and analysis. In this post, we’ll discuss how engineers can log, analyze, and replay CAN data to reproduce real-world behavior in a controlled test environment. These techniques are essential for validation, regression testing, ECU simulation, and in-depth diagnostics—all supported by the advanced features of ATI’s CANLab. 

Capturing CAN Traffic: Building a Reliable Log

Every meaningful CAN analysis starts with accurate data capture. CANLab connects to ATI CAN interfaces to record timestamped CAN or CAN FD messages from one or more vehicle networks simultaneously. 

Engineers can log all traffic or focus on specific messages by filtering by ID, channel, or decoded signal value—keeping datasets concise and relevant. CANLab supports multiple recording formats, including: 

  • ASCII Message Logs – Common format for raw message logs that are supported by popular tools 

  • CSV – For external post-processing and visualization of decoded CAN signals workflows 

  • ATI native formats – For high-speed playback and detailed analysis within CANLab 

The result is a clean, well-structured log file that forms the foundation for analysis, troubleshooting, and repeatable testing. 

Analyzing and Visualizing Recorded Data

Once the messages are captured, CANLab can transform the raw hexadecimal frames into meaningful engineering signals using a CAN database (.dbc). 

Key analysis tools in CANLab include: 

  • Time-based plots – Overlay and compare signal behaviors across time 

  • Message and frequency statistics – Detect missing, delayed, or jittery messages  (see image at right)

  • Search and filter tools – Isolate activity from specific ECUs or subsystems 

  • Multi-log comparison – Load and review multiple log files side by side to evaluate changes between tests or calibration updates 

This data-driven analysis enables engineers to verify fixes, pinpoint faults, and understand system behavior under different operating conditions. 

Replaying CAN Data: Record and Playback Testing

CANLab’s record and playback functionality allows engineers to reproduce captured network activity as though it were occurring live. This bridges the gap between on-vehicle testing and bench validation by enabling recorded traffic to be replayed in controlled conditions. 

Common use cases include: 

  • Regression testing – Replay known-good traffic to confirm consistent ECU behavior after software or calibration changes 

  • ECU simulation – Emulate a missing ECU or subsystem by replaying its messages, enabling dependent systems to be tested in isolation 

  • System validation – Recreate complex network conditions to confirm timing integrity and fault tolerance 

CANLab offers timing control, looping, and synchronization features (as described in its technical documentation), ensuring accurate and repeatable playback for confident testing results. 

Exporting and Sharing CAN Data

Collaboration often requires sharing data in formats compatible with other tools or teams. CANLab provides flexible export options such as: 

  • CSV – Enable spreadsheet-based analysis or import into data visualization tools 

  • ASCII Message Logs – Raw CAN Message traffic 

  • MDF3 Message Logs – Preserve full functionality within CANLab and VISION 

These export options streamline communication between teams and testing environments, supporting internal development as well as supplier validation. 

Real-World Applications

Regression Testing 

Teams can identify unintended software changes by replaying previously captured data. Deviations in timing, signal response, or message behavior reveal regressions before production release. 

ECU Simulation 

When certain vehicle components aren’t available, CANLab can substitute by replaying their recorded traffic. This allows subsystem testing and integration validation without requiring every physical ECU—saving both time and resources during development. 

Wrapping Up

Logging, analyzing, and replaying CAN data fundamentally changes how engineers test, debug, and validate vehicle systems. ATI’s CANLab empowers teams to capture what happens on the network and reproduce it with precision. From real-time logging to replay and visualization, CANLab turns CAN data into actionable engineering insight. 

In the next part of our CAN Bus Blog Series, we’ll move beyond the base protocol and explore Higher-Layer Protocols: CANopen, J1939, and UDS—covering how CANLab supports these standards, how structured data like SPNs and service requests are decoded, and how they’re applied across heavy-duty, medical, and robotics applications. Stay tuned as we continue uncovering the layers of modern vehicle communication. 

]]>Thu, 13 Nov 2025 11:59:05 -0500<![CDATA[Pt. 6 Introduction to CAN Bus]]>https://www.accuratetechnologies.com/blog/post/Part-6-Sniffing-a-Vehicle-s-OBD-II-Network

Sniffing a Vehicle’s OBDII Network

So far in this series, we’ve explored how CAN Bus works, how to capture data, and how to debug messages during development. In this installment, we take the conversation out of the lab and into a live vehicle environment, specifically, the OBDII network.

Whether you’re diagnosing a customer complaint, logging real-world usage, or reverse-engineering manufacturer messages, sniffing the OBDII port gives you direct access to a vehicle’s live CAN traffic. But this comes with important technical and safety considerations.

Passive Monitoring: Listening Without Talking

When you connect to a vehicle’s OBDII port, you’re tapping into one or more in-vehicle CAN networks. Passive monitoring means listening to traffic without transmitting anything back, avoiding the risk of unintentionally sending commands that could alter ECU behavior.

With ATI CANLab, this is straightforward:

  1. Connect your ATI CAN interface (such as a CANary or CANary FD) to the OBDII port using the appropriate cable.
  2. Set your CAN interface to listen-only mode in CANLab’s hardware settings.
  3. Begin capturing traffic to see messages from the powertrain, emissions, and possibly other subsystems (depending on the vehicle’s network gateway).

Pro Tip: Vehicles often have multiple CAN buses. The OBDII port may expose just the legislated powertrain CAN or may be gatewayed to other modules. Knowing the network topology helps interpret what you see.

Logging OBDII Traffic with CANLab

Once connected, CANLab allows you to log and view the OBDII data:
    • Live View + Logging – View incoming messages in real time while saving a log file for later analysis.
    • DBC Integration – If you have the proper database file, CANLab can decode raw CAN frames into engineering units like RPM, throttle position, or coolant temperature.
    • Long-Term Logging – Run CANLab continuously to record extended drive cycles for emissions testing or performance benchmarking.

Example use cases:

    • Capturing ECU diagnostic messages during a road test
    • Monitoring sensor behavior during transient events
    • Building a baseline “healthy vehicle” log for comparison with fault conditions

Pro Tip: CANLab installs an example workspace and several CAN DBC files to decode OBDII PID values.  The workspace can be found in this folder: C:\Users\Public\Documents\Accurate Technologies\CANLab 5.3 Samples

    • “Alt + S” will write the supported PID numbers to the CANLab Output Window.
    • “Alt + P” will start polling the ECU for the PIDs that are in the script pidList array. 

Safety Concerns When Connecting to In-Vehicle Networks

While passive sniffing is generally low-risk, there are still safety considerations:

    • Avoid Active Commands – Never transmit on the network unless you are certain of the message’s function and have authorization to send it.
    • Secure Cables and Hardware – Loose wiring inside a vehicle can interfere with pedals, steering, or airbags. Always secure your setup.
    • Electrical Isolation – Use interfaces that provide galvanic isolation between the vehicle and your PC to prevent damage from voltage spikes.
    • Respect OEM Policies – Many manufacturers have strict rules for connecting to vehicle networks, especially in fleet or warranty contexts.
Remember: in-vehicle testing is not just about data, it’s about safety for the driver, passengers, and the vehicle itself.

Wrapping Up

Sniffing a vehicle’s OBDII network opens the door to real-world data capture and powerful diagnostics. With ATI CANLab, you can log and analyze OBDII traffic safely and efficiently, turning raw CAN messages into actionable engineering insight.

In the next post, we’ll explore Logging, Analyzing, and Replaying CAN Data, including replaying recorded data, applications and format.

]]>Thu, 16 Oct 2025 14:22:39 -0400<![CDATA[Pt. 5 Capturing and Debugging CAN Traffic]]>https://www.accuratetechnologies.com/blog/post/Part-5-CAN-Traffic

In previous installments of this series, we explored what CAN Bus is, how to set up your first network, and how to interpret CAN frames. Now it’s time to put that knowledge to work by actually capturing and debugging real CAN traffic. 

Whether you’re diagnosing an intermittent fault, reverse engineering a message, or validating your system during development, being able to record, filter, and analyze CAN data in real time is essential. 

In this post, we’ll look at: 

    • How to set up ATI CANLab for efficient capture and debugging 
    • How CANLab’s features compare to popular free tools 
    • How engineers use CAN capture in real-world validation and testing 

Setting Up ATI CANLab for CAN Capture

ATI CANLab is designed for professional-grade capture, filtering, and analysis. Once your ATI CAN interface (such as a CANary, CANary FD) is connected to your PC and the CAN Bus, setup is straightforward: 

    1. Select Your Hardware 
      In CANLab, add your interface in the Channel Manager.  This can be done manually or CANLab can automatically detect supported devices. 
    2. Configure Bus Parameters 
      Set the CAN frame type (Classic CAN or CAN FD). Set the bit rate(s) to match the connected network. 
    3. Create a Capture Workspace 
      Organize your capture view with multiple panes, such as a live message list, graphical plots, and a message decode view—so you can see data in different forms simultaneously. 

Filtering and Triggering for Efficient Debugging

Capturing everything on a busy CAN Bus can be overwhelming. CANLab’s filtering tools help you focus only on the data you need: 

  • ID-Based Filters 
    ID Filters can be used with Message Loggers and the CAN Trace window to focus on the messages of interest. There are separate lists for 11-bit and 29-bit identifiers. 
  • Message Highlighting 
    Change the display formatting in the CAN trace window based on Message ID or the value of a signal in the message.   
  • Event Triggers 
    Set CANLab to begin capture based on a message or value appears on the bus. This is especially useful when trying to capture intermittent issues. 

How CANLab Compares to Free Tools

There are popular free options like SavvyCAN and Wireshark with SocketCAN. These tools are excellent for hobbyists or quick one-off captures, but they have limitations compared to CANLab: 

 Feature  CANLab  SavvyCAN  Wireshark + SocketCAN 
 Real-time signal decoding  Built-in CAN DBC support Partial (manual mapping)  Partial (requires external configs)
 Multi-bus synchronized capture  Native Limited  Limited 
 Trigger and filter granularity  Highly configurable Moderate Basic 
 Long-term reliability  Designed for continuous test logging Varies by platform  Dependent on OS stability 

If your work involves production vehicle testing, ECU calibration, or compliance validation, CANLab’s advanced features save time and prevent missed data. 

How Engineers Use CAN Capture in Development and Testing

In real-world engineering workflows, CAN capture and debugging is critical at multiple stages: 

  • Early Development 
    Verifying that an ECU is broadcasting the expected messages and signal values. 
  • Integration Testing 
    Confirming that different ECUs exchange data correctly without ID conflicts or unexpected delays. 
  • Issue Reproduction 
    Capturing the exact sequence of messages leading up to a fault so it can be analyzed later. 
  • Regression Testing 
    Comparing CAN logs from different software versions to ensure no unintended changes were introduced. 
With CANLab, these tasks are streamlined by time-aligned multi-bus capture, automatic decoding, and easy export for team collaboration. 

Wrapping Up

Capturing and debugging CAN traffic is where theory meets reality. Whether you’re troubleshooting a stubborn fault, validating an ECU during development, or ensuring network integrity before production, the right tools make the difference between chasing ghosts and finding answers. 

Free tools can get you started, but ATI CANLab delivers the precision, flexibility, and reliability that professional workflows demand, especially when your test data needs to be accurate the first time, every time. 

In the next installment, we’ll take this knowledge on the road and look at sniffing a vehicle’s OBD-II network, covering passive monitoring, safe connection practices, and real-world logging techniques. 

More About CANLab
]]>Thu, 04 Sep 2025 08:59:57 -0400<![CDATA[End-of-Life (EOL) Product Announcement]]>https://www.accuratetechnologies.com/blog/post/end-of-life-eol-product-announcement

Effective Date: August 2025
End of Sale Date: December 31, 2025 (or until inventory is depleted)

Accurate Technologies Inc. (ATI) announces the End-of-Life (EOL) of several legacy products. These products will be available for purchase until the end date or until current stock is depleted.

 Part Number Product Name Status Availability End Date Replacement Available
 155-0001 VOM – Voltage Output Module Approaching EOL Until stock is depleted 12/31/2025 None
 159-0003
 159-0006
 VID – Vehicle Information Display Approaching EOL Until stock is depleted 12/31/2025 None
 161-0013 EMX AI Breakout Box Approaching EOL Until stock is depleted 12/31/2025 Yes (see below)

Reasoning for EOL

155-0001 VOM

  • In service for over 25 years.
  • Relies on several obsolete components that are no longer available.

159-0003 / 159-0006 VID
  • In service for over 20 years.
  • Relies on several obsolete components.
  • Continued support and manufacturing is no longer feasible.

161-0013 EMX AI Breakout Box
  • In service for over 20 years.
  • Relies on several obsolete components.
  • Replaced with modular breakout box solutions offering greater value, flexibility, and continued long-term support.

Recommended Alternatives for 161-0013

While direct access to EMX Sensor Power Supply (SPS) pins is no longer available in newer breakout boxes, SPS functionality can still be accessed using breakout cables.

Breakout Box Alternatives

 Part Number Description
 161-0015 EMX.BOB.AS64.AI8x2
 161-0016 EMX.BOB.AS64.AI8x3
 161-0021 EMX.BOB.AS64.AI8x1

Breakout Cable Alternatives

 Part Number Description
 150-0164-10FT Cable EMX 160-0005 ASDD614-64SN to unterminated 10FT
 150-0164-6FT Cable EMX 160-0005 ASDD614-64SN to unterminated 6FT

Additional Information

For more information regarding this EOL notice, recommended replacements, or assistance with transition planning, please contact ATI Support:

Contact Support
]]>Mon, 25 Aug 2025 12:10:34 -0400