3 Points of Friction That Slow Vehicle System Development

Laptop on top of automotive engine

Laptop on top of automotive engine

If the end game of control system development is to get your system or vehicle into production, you need to be as efficient as possible at each stage of the development life-cycle. It can be really frustrating, and costly, to get underway with a project and run into roadblocks that could have been avoided with the right tools. We’ve identified three mistakes that can create friction and ultimately slow your project to a halt.

1. Not Thinking About Hardware First

We have a saying around here: Hardware selection drives tool selection. Kevin Alley, Director of Programs at New Eagle explains:

“One of the challenges control engineers face is that when they’re in prototype development they don’t know what kind of controller hardware they’re going to need. If they choose a software platform at the front of their project that doesn’t have the right I/O for what is needed later…they’ll have to start over. That’s going to cost time and money.”

Ideally, engineers should select controller hardware first, and with this in mind: controllers are more than just a piece of hardware. As vehicles and the software that controls them becomes increasingly more complex, the software itself becomes a significantly larger part of the value-added to the vehicle.

Selecting ruggedized, high-quality hardware that supports your ideal software is now a critical choice that needs to move higher upstream in the development process. Your hardware selection impacts your schedule and your budget. But if so much of your vehicle’s value is reliant on its software, you better have the right ECU to support it.

How New Eagle Can Help:

Unless you’re working for the big guys with an ‘unlimited’ budget, it probably makes more sense to use an off-the-shelf controller with an accessible, highly flexible, and open development environment such as Raptor™. You could select one of our many ECU models available at volume pricing, and use it directly with our Raptor development toolset.

If you have an existing ECU you’d like to use, we can port Raptor into it, then you can use it to develop, test and control your vehicle, without friction. Better yet, you can start development today with one of our off-the-shelf ECUs and then easily port your Simulink model when YOUR controller comes online.

And, if you need a custom ECU, we can build you one to match your requirements, leveraging our existing relationships with high-volume automotive-grade ECU suppliers.

Download the Raptor eBook

2. Using the Wrong Development Tools

Engineers love rapid prototyping tools because they’re fast and familiar. Many of them may even have learned the rapid prototyping development environment in school, and want to stay in their comfort zone. We get it and support it.

The key is to understand that most rapid prototyping tools are just that, useful for prototyping only. That’s where they leave you. They are too expensive and don’t have the facilities needed for production. And if you use a rapid prototyping tool that can’t get you to production, or one that you can’t afford –another point of friction is created. We would like to suggest that some rapid prototyping tools can take you to production.

Kevin explains:

“That’s really the core of why New Eagle was founded. We wanted to offer controls engineers the same development style that they were used to, but with the added benefit of being able to take it all the way to production. The challenge was making high-quality controllers for them to run on that were affordable, and we have done that with our volume pricing.”

How New Eagle Can Help:

We created Raptor-Dev so that engineers could quickly create custom software in a highly effective development environment, one that is already familiar to many.

Raptor-Dev is an open ECU development environment that lets you quickly develop in the Simulink environment and run on production embedded hardware without the friction common to embedded system development.

3. Using a Disparate Set of Tools

This arguably creates the highest volume of headaches. Mismatched tools mean manual adaptations that eat up your time, create more friction, and introduce another source of costly errors. Imagine running into roadblocks that require hand-writing new code at each of these stages:

  • Design
  • Development
  • Calibration
  • Validation
  • Testing
  • Service

Here’s Kevin:

“What if, at any stage of development, you ran into a problem, and you could quickly change code in minutes vs. taking a week or more to get a new version from your vendor? How about changing the function of the code in seconds using a streamlined calibration interface vs. rebuilding everything. These quick-cycle iteration capabilities over many iterations will really add up – saving you time and cost.”

How New Eagle Can Help:

The Raptor Platform™ is an end-to-end solution that allows you to work within a holistic development system that takes you through to production, quickly. Engineers can design, develop, calibrate, validate, manage and service their vehicles all within a compatible suite of tools.

Kevin explains the not-as-obvious value of the Raptor tool-chain:

“We’ve heard from our customers that one of the things they really appreciate is the fact that they can keep their IP in-house because Raptor eliminates the need to constantly submit requests for software changes to an outside vendor – instead they can just do it on their own. When we say ‘Take Control’ here at New Eagle, that’s what we’re talking about. Helping engineers take control of their project from start to finish.”

If you’re interested in getting started with Raptor, consider our Raptor Starter Kit. It includes Raptor-Dev, Raptor-Cal & Raptor-CAN.

You can also read more about each of the tools in the tool-chain in our eBook about the Raptor Platform.

Download the Raptor eBook

Raptor Power User Tip: Implementing LIN Bus Master Using Raptor-Dev

Local Interconnect Network (LIN) provides a low-cost communication network alternative to CAN where lower bandwidth and less versatility are acceptable. LIN is a serial communication protocol that efficiently supports the control of mechatronic nodes in distributed applications. LIN uses a master/slave bus access concept with one master per bus.

LIN is a message-based protocol with message identifiers and message content similar to CAN. Also similar to CAN, the LIN standard does not specify the content or meaning of the messages which are to be transmitted within a LIN network, which are application specific and up to the application developer. The LIN standard introduces the LIN description file (*.LDF file) which is used to describe the LIN network. This file is analogous to a the *.DBC file used in CAN networks.


In a similar way to how Raptor-Dev automatically handles the details of CAN message packing and unpacking for you based on the DBC file using code-generation, the details for LIN messages are handled with Raptor-Dev for you using the LDF file. This user tip shows you how to configure a simple LIN master that communicates with two LIN slave nodes. The sample model is available for download.

Below you will see the model, starting at the top-level (with the model shown above). First, you must define the LIN bus using the “LIN Definition” block. This configures the LIN hardware driver for a particular channel, providing the baud rate and time base. This block also configures the software driver based on the LDF file you specify.

Next looking inside the ‘Foreground’ block, the architecture of the LIN network is more apparent:

LIN Master

The master (GCM80) will operate according to the schedule(s) defined in the LDF file–if one is present in the LDF. If there is no schedule present in the LDF, Raptor-Dev will automatically create a simple round-robin schedule for you based on the messages used in your model. In this example, there is only one schedule defined in the example LDF file, so there is one schedule available in the “LIN Set Schedule” block. You can define multiple schedules from which to choose. Schedule 0 will be “Empty,” meaning no schedule is selected, thus no messages will be sent on the bus.

LIN Set Schedule

Referencing the LDF with a text editor, shown here, you can see how the schedule is composed.

schedule tables

In the example model, using the“LIN_SCHED” variable as an adjustment block in Raptor-Dev, you are able to change the value to select a different schedule in Raptor-Cal. This will cause the bus traffic on the LIN network to change.

It is helpful to be able to read the state of the current schedule, which can be done with the “LIN Get Schedule” block:

LIN Get Schedule

As with CAN, errors may occur with the message transmission in LIN. The “LIN State” block allows monitoring of the LIN bus:

LIN state

Now, having configured the master, it is important to recall the way in which slaves operate on a LIN bus. The master will tell the slaves what to do, and when to do it according to the schedule.

LIN Master 2

In this example, the master sends data to a slave with the “LIN Tx Message” block, and data sent from a slave to the master is received with the “LIN Rx Message” block. These blocks handle all the packing and unpacking for you automatically based on the LDF file identified in the LIN Definition block.

LIN Tx Message

LIN Rx Message

Within these subsystems for sending and receiving LIN messages, a LIN Trigger block can be used to do extra logic based on the transmission or reception of a message. For receiving messages, the trigger will fire AFTER the message arrives and the receive block output data ports will contain the newly arrived data. For transmitting messages, the trigger will fire BEFORE the message is sent to the bus, the data in the outgoing messages will be collected from the transmit block if the block is inside the trigger callback.

In this example, a counter is incremented every time a particular frame is sent, and another counter is incremented every time a particular frame is received:

LIN Trigger

Triggers can be particularly helpful for creating internal logic for handling LIN frame events, and also to assure that you are processing or transmitting the latest data.

This user tip has shown how LIN is supported within Raptor-Dev. Hopefully, it will feel very familiar since LIN is exposed in the tool in a very similar way to CAN.

Download the Raptor eBook

ECUs: More Than Just A Piece of Hardware


Raptor_ECUChoosing an Electronic Control Unit (ECU) for your EV / HEV / Autonomous vehicle is a huge decision with implications way beyond vehicle control. While some people see it as ‘just a piece of hardware’, we believe your ECU choice greatly impacts your development process and ultimately what you’ll be able to deliver, and when. The supervisory or vehicle control unit you choose will affect your costs and even your to time to market in ways you may not anticipate.

Continue reading “ECUs: More Than Just A Piece of Hardware”

Understanding The Raptor Application Monitor Tool

raptor application monitor tool

The Application Monitor is a tool within Raptor-Dev that adds continuous run-time checking within your running application. It’s a useful tool for Embedded Model-Based Design (eMBD), especially if you begin to push the limits of the embedded hardware. Debugging software created in Simulink with Raptor is a little different than debugging a text-based programming language (like Python, C/C++, or MATLAB). For one, the generated code created from a Simulink model with Raptor generally won’t be familiar to the author of the model, which is kind of the point. It is the power of code generation that lets you go fast not having to worry about the detailed code. Secondly, the built software is programmed onto a sealed electronic control unit (ECU) with no hardware debugging attachments. Thankfully, with a robust, validated tool like Raptor-Dev and the proven code-generation technology from The Mathworks, the kinds of issues that require a hardware debugger are resolved already and available in the proven software blocks for your use.

Debugging an application without these debugging tools could be as simple as toggling an output on the ECU or changing the state of the system to something you would expect; however, some errors are more difficult to track down such as those in memory management which can cause intermittent microcontroller resets and other non-deterministic behavior. The App Monitor comes in handy when the system can’t be debugged by traditional debugging methods.

bricked_moduleNo controls system engineer wants to tote around a bricked module. Using the App Monitor offers a way to determine what might be resetting the processor by pausing the application during runtime. By stopping the application before a reset, the state of the module is available to be seen by the user. When the application is stopped, user-accessible variables are available for viewing.


Download the Raptor eBook

How Do I Use The Application Monitor?

By creating a model and simply dropping the “App Monitor” block onto the top-level system, we’ve done most of the heavy lifting.

monitor-application-toolThe parameters are as follows:


  • Enable App Monitor: The benefit of being able to control this is to easily remove debugging features in a production code build, after testing, such as with a script.
  • Startup Action:
    • App Monitor Disabled: Causes the App Monitor to be disabled (can also be set through calibration – see next parameter).
    • Run: Runs the software on startup
    • Pause: Pauses the software on startup
  • Add Startup Action Adjustment: This adds a calibration in Raptor-Cal under “Startup” that can be configured:
    • When set to pause, the application will pause on startup, as seen here. The foreground counter is at 0. The idle time is 0% because the application has never entered the foreground loop that updates this variable. Otherwise it would be at 100%.


  • Minimum Idle Time: The minimum percent of time that the processor can be idle before the App Monitor pauses the application.
  • Maximum Thread Time: The maximum percent of time that any particular thread may be active before the App Monitor pauses the application when checked against the Percent Overrun Limit.
  • Percent Overrun Limit: The percent of time a thread may be above the maximum thread time.

Within our model, we’re able to add more App Monitor logic that can give insight into CPU usage. The blocks shown below allow accessing App Monitor information at runtime. We’ll start by adding a few blocks. Stop the application by toggling “App Monitor Stop”. This kind of control is powerful if you can generate logic to stop the application when you prefer (for instance, by setting this stop point within a particular function call). This tag is viewable in Raptor-Cal.

adjustment-app-monitor-stopWhile stopping the application can help, the ability to see the underlying system parameters is more helpful. You can access this information by using the “App Monitor Measurement” block.

adjustment-app-monitor-stopVarious measurements include:

  • Idle Time: The measured percent of time that the processor is idle.
  • Trigger Usage: The percent of the scheduled time rate that the last execution of this rate task consumed. In this example, we have selected the “Foreground”. On all modules, the foreground trigger is fired every 5ms by default — except for the BCM48 and display, where the foreground rate default is 10ms.
  • Trigger Period: The measured amount of time since the last firing of a trigger.
  • Platform Items: On certain ECUs there are additional application monitoring data that is exposed by the base software. These platform-specific items are in this area.
  • Percent Overrun: The measured percent of time that a thread has overrun its time schedule.
  • Trigger Longest Run: The longest task execution time, measured in milliseconds.
  • Number of Overruns: A count of the number of times that a thread has exceeded the amount of time it’s allowed to run.

Adding these measurements to the model provides a simple application to show the inner-workings of the application, which is available for download.

For this demonstration, you can configure the App Monitor calibrations in Raptor-Cal to see how it works. In this screenshot, notice the main application counter is significantly lower than the AppMonitorExecutionCount (App Monitor execution counter) when the AppMonitorState is set to “Paused” (pausing the application).


What To Take Away?

The Application Monitor allows for application debugging in settings where conventional debugging methods can’t help you. By stopping an app and/or seeing thread usage within the app, you can take better steps toward getting your application up and running.

Download the Raptor eBook

August 2019 Raptor News

august raptor news 2019

Raptor Logo

If you’re a Raptor user with software maintenance, make sure to get the newly released update, Raptor 2019a2_2.0.  This version features key improvements, including:

  • GCM80: LIN Master Implementation, CAN queuing and XCP connection stability improvements
  • GCM70: Programming configurability improvements
  • GCM196: Output49, INPUT 31/32 updates
  • BCM48: CAN Transmit improvements
  • Displays: Initialization robustness enhancements, touchscreen button robustness improvements, display blocks interface fixes
  • J1939: added newly defined PGNs from standard
  • DBC-based CAN Message and Packing blocks bug fixes
  • Fault Manager feature additions and enhancements
  • Datasheet expansions and updates

Review the full release notes on our wiki, or download the Raptor-Test regression reports here. 



Raptor 2019a Webinar on August 23

Tune in at 2 p.m. EST on August 23, 2019 for our in-depth webinar on Raptor 2019a. Not only will you learn all about the latest Raptor update,  but you’ll also get a peek into what’s coming next to the Raptor Platform this year. 

raptor laptop



Introducing the VeeCAN 500

This dash-mountable, low-profile, 5-inch color display is the latest addition to the Raptor product line. Wrapped in a rugged, environmentally-sealed enclosure, it delivers a sleek, modern look while remaining easily programmable in the MATLAB/Simulink environment using Raptor-Dev. Get the specs on our wiki, or contact our sales team for information about how to purchase. 

veecan500 display



Raptor Training Sept 17

Get hands-on experience with Raptor during our three-day training course in Ann Arbor, Michigan on September 17-19, 2019. During this program, you’ll learn how to create real-world applications with Simulink and Raptor as you create models, build and program an ECU, and calibrate in real time with Raptor-Cal. 

raptor training



Get Hands-On Raptor Training In September

Raptor training cover image september

Join us for our popular Raptor Training program where participants will receive hands-on training with our embedded model-based controls, Raptor platform. Participants will come out of this three-day course with hands-on experience with the Raptor-Dev and Raptor-Cal tools.


raptor training

Tuesday, September 1 7  – Thursday, September 19, 2019

Defense Corridor Center for Collaboration and Synergy

7205 Sterling Ponds Court

Sterling Heights, Michigan 48312



If you can’t attend the September training session, reach out to our sales team to inquire about additional options customized to your needs. Also, be sure to subscribe to New Eagle’s Raptor newsletter to stay informed about Raptor toolkit’s tips and tricks, updates and future classes.  

What to Expect in Raptor Training


raptor training agenda


Attendees will use a throttle body controller project as an introductory guide to Raptor-Dev in the MATLAB/Simulink library. This will allow them to create a model intended for a target piece of hardware. Then, participants will use Raptor-CAL to flash the compiled software onto the hardware and make live calibratable adjustments on the flashed ECU.

On-Site, Customized Raptor Training Options

Can’t make it or prefer a more personalized training of New Eagle’s embedded model-based development tools? Our Raptor experts can travel to your team’s work facility for hands-on instruction catered to your needs.  

To learn more about these options and schedule a training at your location, email us at [email protected].  

We look forward to seeing you in class!

3 Myths About Rapid Prototyping Tools For Controls Development


Rapid prototyping tools allow quick iterations of control software code so we can learn what works and get the system functioning. Unfortunately, most rapid prototyping tools available today for system development fall into two categories:

  • The very expensive, highly capable options available to OEMs
  • The cheaper options meant for tinkering or hobbyists

Fortunately, there’s a third category: affordable, production-ready rapid prototyping tools that are easy-to-use.

Let’s look at three myths about rapid prototyping tools for the development and production of autonomous or EV/HEV vehicles.

Myth 1: Rapid Prototyping Tools Can’t Make Production Software

We’ve heard that rapid prototyping tools are great for innovation, but don’t have the capability to handle the detailed challenges and rigor of production system development.


Rapid prototyping tools ARE great for innovation, because they let you iterate quickly, additionally, we’ve been enabling our customers to use those SAME tools for production for more than 15 years. New Eagle’s Raptor suite of tools is specifically designed for engineers developing systems and vehicles meant for mass production. Each Raptor software build automatically injects production-capable calibration management and data-collection capabilities to support production-oriented workflows and tools. Beyond that, Raptor has field-proven Fault Management & Diagnostics functionality engineered to allow application development targeting real-world emissions compliance standards such as CARB CCR 1968.2 (OBD-II) and CCR 1971.1 (OBD-HD).

Raptor Platform Overview

Myth 2: Rapid Prototyping Tools Can’t Handle Production Development Processes

We’ve heard engineers are more comfortable using legacy processes to achieve compliance with safety standards, because they are not sure how newer technologies map onto standards such as ISO 26262.


Since its inception, ISO 26262 has provided a path to compliance using Model-Based development, providing ISO 26262-6 Annex B with guidelines. The revised ISO 26262 : 2018, which was recently released, provides enhanced guidance specifically for model-based development with code-generation and software safety analysis.

Raptor is built upon the MathWorks code generator for which MathWorks offers an IEC Certification Kit specifically for ISO 26262. Our production customers can engage our safety-certified engineers to prepare a plan tailored for their project.


Portions of this image are from the International Standard ISO 26262-6 Second Edition 2018-12

Download the Raptor eBook
Myth 3: Automated Code Means Added Hardware Costs

Some engineers believe that rapid prototyping and code-generation are too inefficient to target cost optimized controllers for volume production. They think it will increase their overhead which would force a more expensive processor and more memory. They believe you must hand-tweak software code and use the cheapest possible controller.


Machine-generated code does not add costs, and is more accurate than human-generated code. The repeatability of machine-generated code, combined with the optimizations it can perform, is often favorable to its human-generated counterpart.

Raptor is built on The MathWorks proven code-generation technology which has continued to improve in quality and efficiency over the past fifteen years and provides a cost-effective way to accelerate your vehicle development.

Most systems development projects we consult on (low to medium volume) involve conversations about the Nonrecurring Engineering Costs (NRE) because they factor heavily into the end system cost, particularly at these volumes. We advise our clients that it doesn’t make sense to spend extra budget on engineering just to shave a few dollars off the controller price.

Production-Ready Rapid Prototyping Tools In Action:

A great example of our production-ready rapid prototyping tools in action is our work on the Walmart WAVE.

Walmart wanted to build a vehicle with an alternative-fuel powertrain for cleaner shipping. The concept involved an advanced on-highway hybrid Class 8 truck that would one day become the Walmart Advanced Vehicle Experience (WAVE).

Walmart enlisted our team to help develop the complicated control software and electric powertrain architecture. We quickly created a working system and built a custom interface into the WAVE’s microturbine controller, which facilitated the proprietary protocol over a serial interface.

In the end, our rapid development tools allowed Walmart to meet its timeline goals and showcase how green technology can be leveraged on-highway for cleaner shipping.

From Concept to Production, Faster

As the EV/HEV and autonomous markets mature, development tools will continue to evolve. Now you know that there are rapid prototyping tools that can stand up to the demands of production system development.

Remember, the right tools can help you with developing, designing, testing and validating your system so you can reduce risk and cost and get to production that much faster.

Download the Raptor eBook

June 2019 Raptor News

raptor 2019a

With summer, comes the biggest update to the Raptor platform of 2019–Raptor 2019a. Plus, get up-to-date on the latest articles, products, and training opportunities designed to help you take control of your project and overcome mechatronic control system challenges.

Raptor 2019a 

Raptor 2019a brings notable updates to the Raptor-Dev, Raptor-Cal and Raptor Test tools.  Check out the release notes on our wiki, or skim what’s new below:

Raptor-Dev 2019a

View our Raptor-Test regression reports for the Raptor-Dev 2019a_1.0 release here.

  • BCM48: CAN queue improvements, EEPROM driver enhancements, added Duty Cycle measurements for frequency inputs
  • GCM/ECM196: enhanced Application Monitor functionality, added redundant EEPROM capability, CAN2/3 robustness fixes, added J1939 support
  • GCM80: CAN queue improvements, CAN messaging fixes, added J1939 support
  • Displays: Updated default EEPROM storage logic, startup display improvements
  • Enhanced support for third-party calibration tools
  • Fault Manager enhancements
  • Improvements to the DBC CAN message blocks
Raptor-Cal 2019a
  • Transfer-Cals improvements
  • Stripchart autoscaling
  • Additional settings for compatibility with J1939
  • Resolved issues with Fault Manager support for Motohawk ECUs
  • Stability and performance enhancements
Raptor-CAN 2019a
  • Support for multi-bus simulation
  • Floating-point simulation precision fixes
  • Gateway function tool will now pass through new messages after initialization
  • Installer robustness improvements
  • Licensing updates
Raptor-Test 2019a
  • Improved initial ECU connection time
  • Added support for GCM70 and GCM80
  • Added additional script actions (Reflash, VerifyRunningSoftware, CANChannelUpdate)
  • Fixed enum variable handling
  • Custom plugin interface enhancements
  • Improved RPG file version migration
  • Licensing updates

Raptor Logo

Regression Testing

Inside every new Raptor-Dev release announcement, there’s a link to download the Raptor-Test regression reports that outline all individual regression tests ran on the software, noting whether or not those tests passed. If you’ve ever wondered what regression testing is–let alone, why it’s both useful and necessary for programs–read this helpful article to learn all about it.



Telematics Gateway Unit 

This telematics gateway unit is summer 2019’s newest addition to Raptor Telematics product line, manufactured by a global leader in telematics manufacturing. This unit meets automotive quality standards, approved by major US and European OEMs, heavy-duty vehicle manufactures, and agricultural implement suppliers–a capability not found in most rugged embedded controllers! 

To learn more about this new hardware,  contact our sales team or click the button below.


telematics gateway unit
Don’t Miss Raptor Training on September 17-19, 2019

Registration for the fall Raptor Training Course is now open! Build your skills with this hands-on, in-depth course, taught by New Eagle’s Raptor experts. Sign up now to save your seat, or contact our team for more information.



raptor training


Be among the first to know about the latest Raptor updates, upcoming events and training opportunities, plus get exclusive Raptor tips by subscribing to our mailing list. For more great ways to stay up-to-date with New Eagle, connect with us on social. 

What is Regression Testing and Why is it Necessary?

regression testing with raptor test

Have you noticed that, inside every new Raptor-Dev release announcement, there’s a link to download the Raptor-Test regression reports? In that download, we outline information for all of the individual regression tests run on software and whether or not those tests have passed. But what exactly is regression testing, and why is it necessary? Before you break out your old stats notebook to find out, know that regression tests have nothing to do with variable correlation–you’re thinking regression analysis.


What is Regression Testing?

Throughout the software development life cycle, engineers create a suite of test cases to validate software against the associated test case prior to developing additional features. However, software development isn’t always linear. As software developers generate code, functions are added to enhance functionality or to respond to requirement changes. Not to mention, revisions are often necessary due to obligatory bug corrections or performance issues. Through this continuous evolution and expansion of software, it’s necessary to retest and confirm that new code doesn’t alter the existing functionality of the system. To do so, engineers will frequently run the previous test cases to prevent software modification from having adverse effects on existing code. This is referred to as regression testing.


Universal Regression Rig (URR)


Think of the word regression in terms of its meaning “the act of going back to a previous place or state.” It tests the software backwards, making sure new functions don’t break existing performance.

The Universal Regression Rig

Over the years at New Eagle, we focused on improving the regression testing method. Through this development, we built a Universal Regression Rig (U.R.R) to test software packages generated in Raptor-Dev on our Raptor based ECUs. When first developing this system, we concentrated on

  • Replacing our existing test boards with a more robust and repeatable system
  • Upgrading our testing procedures using a selection of advanced hardware
  • Organizing and consolidating our testing hardware
  • Streamlining our testing process to save time and improve the quality of our software systems


Universal Regression Rig Cover 

Built with aerospace-grade testing hardware, this rig is capable of complete I/O testing on up to eight Raptor ECUs. It also handles most (soon to be all) of the hardware circuit types supported by the various Raptor ECUs. Designed to ensure that if something doesn’t pass, the U.R.R. runs tests automatically so that our engineers can address the software rather than manually debug the rig itself.

Download the Raptor eBook
Why Regression Testing is Necessary

Now that you know what regression testing is and how it’s done, let’s talk about why it’s necessary. Regression testing is a part of all software development and maintenance. If a team fails to validate the functionality of the source code prior to release, errors can occur. The result of those errors can cause negative effects on those using the system. This is why it’s necessary.

However, disadvantages of regression testing do exist. It can become incredibly extensive depending on the complexity of the software. Why? Test cases are continuously added as software progresses. With both developing and running a hefty suite of test cases, regression testing becomes time consuming, expensive, and requires an advanced set of resources. In fact, much of a project’s budget and resource allocation is often set aside for regression testing.

Regression Testing Techniques

To offset the above issues, there are techniques to mitigate the time and cost associated with regression testing. To start with, try these three main techniques: Retest All, Regression Test Selection, Test Case Prioritization.

Regression Testing

Going back to our improvements on regression testing, we first test critical systems, followed by functional systems, and, finally, non-functional systems. This allows us to monitor software change modifications. If a program requires, we can execute performance testing. This test tracks the quality of the output by testing the system and monitoring the feedback response. As a whole, this entire process confirms that the system performs to customer expectations. It also measures the outcome in regards to user experience. For instance, in our drive-by-wire (DBW) system, we run tests to validate system command sends to turn the steering wheel. The wheel both turns the proper amount, indicating proper functionality and smooth turns, creating an enjoyable driving experience for passengers.

Testing Raptor Releases

When applying regression tests to Raptor, we run them against each internal build of Raptor-Dev with our Continuous Integration (CI) server. Our engineers integrate source code into our shared repository. From here, the CI server monitors our source code after each check-in. This automatically builds and tests the product to identify any potential errors. If an error occurs, the server alerts our team of the regression. The alert allows them to detect and correct problems early on. With this automation, we receive the added benefit of accelerated software releases.

The Three Stages of Regression Testing

We continue testing on every version of our Raptor Software Tools by pushing them through the three stages of regression testing. These three stages are software-only, processor-in-the-loop, and hardware tests.

Software-only tests ensure that each model previously built will continue to build. Every potential software release is tested across every possible Matlab Version currently supported by Raptor-Dev. These tests determine if the software is functioning correctly and identifies if any platform specific issues arise. Our engineers use software-only testing to guarantee that the new Raptor-Dev release will function for all customers across all supported platforms.

Processor-in-the-loop testing assures that each software version runs properly on the intended hardware. Raptor-Test scripts run against the hardware integrated with the new software release to validate whether all major functions work properly. This stage tests major features, such as interpolation tables, fault manager, and the J1939 protocol library.

Hardware tests, performed on our U.R.R., establish whether the hardware inputs and outputs function through all possible scenarios according to customer specifications with the new build of Raptor-Dev. Once a software package is flashed onto an ECU, the test module interfaces with a coordinator module. Then, test scripts are run to transmit and receive sensor and actuation signals between the two modules. Signals, such as analog inputs, are then rendered to the target hardware and become verified. Lastly, the coordinator hardware receives the test outputs to determine proper functionality for actuation signals. These signals include PWM and digital outputs (I/O).

Building Validation with Raptor-Test

Raptor-Test is a powerful software tool that, in conjunction with a test bench setup, facilitates testing of model-based software against a system’s requirements through simulated hardware-in-the-loop (SimHIL). SimHIL testing is a control systems validation strategy. It uses simulated I/O to verify that the software functions match the application requirements. By using a graphical PC interface, users quickly create and execute a test script over a USB-to-CAN interface, automating a once error-prone, manual testing process.

Raptor-Test configuration can vary with the application’s testing requirements. Some applications only require a PC to run Raptor-Test, a Kvaser cable for CAN-to-USB connection, and the ECU under test. For more complex applications, Raptor-Test can interface with both a Test Module and a Coordinator Module (which typically runs a plant model), transmitting and receiving simulated sensor and actuation signals between the two modules.


Building a validation test plan with Raptor-Test uses automation to reliably and repeatedly test your software changes. Ultimately, this improvement gives you greater confidence in your software, putting you on the path to production.

Develop Your Solution with the Intended Results

Software modifications occur throughout the development cycle, and regression testing is often tedious and overwhelming. However, it’s vital for ensuring your end product functions as intended. If you’re looking to develop a program that requires efficient and affordable regression testing prior to your solution’s release, contact New Eagle.

Download the Raptor eBook

What to Expect from Raptor™ 2019a

raptor 2019a release

Coming this week, our Raptor™ dev team will publish the Release Notes for the next major Raptor™ release, Raptor 2019a. See below for what improvements have been made. Plus, get the recap from the MathWorks Automotive Conference, learn more about upcoming Raptor training opportunities, and find out great ways to stay up-to-date with New Eagle events and the latest Raptor enhancements.

What’s New with Raptor 2019a

Raptor 2019a brings key improvements to Raptor-Dev, Raptor-Cal, Raptor-CAN, and Raptor-Test. Here’s what to expect: 

Raptor-Dev 2019a
  • BCM48: CAN queue improvements, EEPROM driver enhancements, added Duty Cycle measurements for frequency inputs
  • GCM/ECM196: enhanced Application Monitor functionality, added redundant EEPROM capability, CAN2/3 robustness fixes, added J1939 support
  • GCM80: CAN queue improvements, CAN messaging fixes, added J1939 support
  • Displays: Updated default EEPROM storage logic, startup display improvements
  • Enhanced support for third-party calibration tools
  • Fault Manager enhancements
  • Improvements to the DBC CAN message blocks

View our Raptor-Test regression reports for the Raptor-Dev 2019a_1.0 release here.

Raptor-Cal 2019a
  • Transfer-Cals improvements
  • Stripchart autoscaling
  • Additional settings for compatibility with J1939
  • Resolved issues with Fault Manager support for Motohawk ECUs
  • Stability and performance enhancements
Raptor-CAN 2019a
  • Support for multi-bus simulation
  • Floating-point simulation precision fixes
  • Gateway function tool will now pass through new messages after initialization
  • Installer robustness improvements
  • Licensing updates
Raptor-Test 2019a
  • Improved initial ECU connection time
  • Added support for GCM70 and GCM80
  • Added additional script actions (Reflash, VerifyRunningSoftware, CANChannelUpdate)
  • Fixed enum variable handling
  • Custom plugin interface enhancements
  • Improved RPG file version migration
  • Licensing updates

Note: To access the latest updates, you’ll need to have a maintenance plan that’s up-to-date. Get started with purchasing a maintenance plan by selecting the button below.

MathWorks Automotive Conference Recap

At the end of April 2019, New Eagle made its debut appearance as an exhibitor at the MathWorks Automotive Conference in Plymouth, Michigan. There, we shared information about embedded model-based development with Raptor™, an official MathWorks Partner product, while demonstrating our latest Raptor autonomous control solution, our drive-by-wire kit for the Chrysler Pacifica.

mathworks conference picture

You can see the drive-by-wire kit in-action on our YouTube channel and check out photos from the Mathworks Automotive Conference on Instagram.

Get Trained on Raptor

For new Raptor users, Raptor Training is one of the best ways to learn the fundamentals of embedded model-based development using the platform.

In this three-day, hands-on course, attendees create real-world applications using Matlab/Simulink and Raptor™, crafting models with Raptor-Dev, generating code, programming an ECU, and calibrating in real time.

This program is ideal for control system, application, and embedded software engineers, as well as technical program managers.

To register for the next session on September 17-19, 2019, click the button below.