At DMC, we’ve been at the forefront of this evolution, building robust, scalable, and future-proof battery test solutions for major OEMs, EV startups, and energy labs. As part of our journey, we’ve continued to work with a variety of legacy and cutting-edge battery cycler platforms, including a longtime staple in the industry: the Aerovironment battery cyclers, now rebranded under Webasto Charging Systems following their acquisition.  

If you walk into a battery lab or R&D center today, there’s a good chance you’ll still spot AV-900, ABC-150, or ABC-170 cyclers humming away in a corner. These workhorses have been around for years and have built a track record for staying accurate and dependable under heavy use. They’ve been put to the test on everything from older lead-acid cells to the newest high-performance lithium-ion packs, and they’re still getting the job done. The challenge isn’t the hardware—it still performs as reliably as ever, but the built-in software tools haven’t evolved alongside the rapid changes in battery testing. Many of the original integration options now feel dated. The good thing is, modern automation platforms and updated integration methods make it possible to breathe new life into these proven systems. 

Modernizing Control & Automation with LabVIEW and TestStand

At DMC, we’ve built dozens of test systems that interface with Webasto/Aerovironment cyclers using a variety of control strategies.

Common strategies include:

• Remote Operation System (ROS) scripting, which requires C-based development, offers basic command-level access—but lacks user-friendly interfaces and extensibility for long-term test programs.  
• Legacy DCOM Drivers for Windows applications like LabVIEW have been available but are notoriously outdated, lacking support for modern toolchains and requiring extensive debugging.  

To simplify the process, DMC has developed custom LabVIEW drivers, reusable APIs, and scalable frameworks that integrate Webasto cyclers into full-featured test automation platforms.

CAN-Based Communication remains the most effective, open, and performant option for high-speed integration—especially for systems with dual outputs or demanding test sequencing. These DMC solutions are built using NI LabVIEW, TestStand, and CompactDAQ/PXI platforms, often tightly coupled with MES systems, high-speed instrumentation, and safety interlocks.  

Whether retrofitting an older AV/ABC cycler or building a new test stand that supports multiple equipment types (Webasto, Bitrode, Chroma, Arbin, etc.), we ensure operator-friendly UIs, data-logging pipelines, and real-time feedback for test traceability and compliance.  

DMC has expertise and proven software control routines to support these common Aerovironment/Webasto cycler models:

• MT-30
• ABC-150
• ABC-170 / CE
• ABC-600
• AV900 / 900-EX

Typical Use Cases We’ve Enabled

• End-of-line (EOL) validation of high-voltage EV packs
• Functional verification of Battery Management System (BMS)
• Remanufacturing and warranty diagnostics
• High-throughput cycling for R&D across multiple chemistries
• HiL simulation of charge/discharge behavior with Webasto cyclers

In all cases, we help customers move beyond “bare-bones” PC control to a fully automated, traceable, and scalable test environment.  

Should You Build it Yourself or Work with a Partner?

DMC brings decades of expertise, a deep portfolio of turnkey battery test systems, and partnerships with industry leaders like NI, Webasto, and Microsoft. So, whether you’re modernizing a legacy test bench or developing a brand-new validation platform, you don’t need to reinvent the wheel or the driver stack. We’re here to help you accelerate development, reduce risk, and build for scale.  

Let’s Talk Battery Test Automation

Want to bring new life to your AV/Webasto cyclers? Looking to scale your test infrastructure with modern tools? Contact us to learn more about how DMC can help you integrate, automate, and future-proof your battery testing workflow. 

The post Modernizing Battery Testing with Webasto Cyclers and LabVIEW Integration appeared first on DMC, Inc..

The Battery Simulator System delivered by DMC provides the ability to test BMS devices using a Hardware In the Loop (HIL) testing approach. This HIL testing is performed before those devices are fully incorporated into the large battery packs they are designed to monitor and manage. The system provides software-controlled simulated signals for all input sensors connected to the BMS and provides the ability to measure relevant outputs and responses from the BMS. This makes it possible to perform fully automated testing and validation of BMS functionality across any realistic range of input conditions the device may encounter in field operation.

Table of Contents

• System Introduction
• System Details
  • Definitions
• Overview of Hardware System
• System Enclosure
• Battery Stack Simulation
• Cell Voltage / Current Measurement Module (Optional)
• Battery Stack Simulator Connections
• Temperature Sensor Simulation Module
• PXI Chassis to Controller Interface
• Software Driver Libraries for System Control
• Safety / Interlock Functions
• National Instruments / LabVIEW Experience
• Test and Measurement Experience
• Related Past and Current Projects

System Introduction

The Battery Simulator System leverages the DMC Battery Testing Platform hardware and software. DMC’s modular Battery Testing Platform incorporates open software and hardware technologies along with flexible and reliable subsystem components and instruments which are completely customized to the end user’s specifications.

The Battery Testing Platform is built around high-quality off-the-shelf hardware assembled from a variety of vendors, including Pickering Interfaces, National Instruments (NI), Lambda, and Agilent, among others. Selection of individual instruments in the DMC system is based completely on required performance, not allegiance to a single hardware vendor.

The system can simulate a stack of 108 battery cells in series and 50x 4-bit temperature sensors. The system was delivered with source code libraries for low-level driver functions that provide full control over the available functionalities of the Battery Simulator System. This software code is based on pre-existing software modules, which were assembled and customized to accommodate the customer’s specific test system and test application. DMC did not develop a higher-level test execution control application as the customer wished to develop their primary test control application themselves.

System Details

Definitions

• BMS: Battery Management System – An electronic system for managing a rechargeable battery by continuously monitoring the battery state, calculating and reporting data on the battery, performing safety functions in fault conditions, performing cell balancing functions, etc.
• NI: National Instruments, Inc.
• PXI: Programmable eXtensions for Instrumentation – Hardware platform for test and measurement IO
• DMM: Digital Multi-Meter – An electronic measurement device, commonly capable of acquiring high-resolution voltage, current, resistance, or capacitance measurements, as either single-point measurements or waveform captures
• DUT: Device Under Test – Client’s BMS device to be tested

Overview of Hardware System

A high-level functional diagram of the DMC Battery Simulator System is shown below.

System Enclosure

The Battery Simulator System is built upon the Media Director Lectern V2, a portable (wheeled) rack-mount enclosure desk, as shown below.

This mobile desk provides 32U of total rack-mount space in two separate columns for mounting primary system components, including 6U of rack-mount space in the upper portion of the lectern just beneath the desk surface.

Controller and Accessories

The primary controller for the Battery Simulator System is a rack mount PC. This PC serves as the primary controller for the test system and runs a LabVIEW test application developed by customer engineers.

A listing of the performance specifications of this PC is provided below.

• Processor(s): Intel® i7 – 2600 (LGA1155) Quad Core Processor 3.4GHz/8MB Cache
•  2U Riser Card PCIe – x16, x4, x1
• Memory – DDR3: 16 GB DDR3-1333/PC3-10600
• Hard Drive: 2TB SATA III 7200RPM
• Optical Drive: Plextor® PX-890SA 24x DVD±R/W
• Video Card: PCI-EXPRESS RADEON HD6450 1GB/PCIe 2.0 (Dual Monitor)
• Operating System: Microsoft® Windows® 7 Professional 64-bit OE

The system includes a license for the LabVIEW NI Developer Suite package (the most comprehensive and full-featured package offered by National Instruments) to ensure the customer has access to the complete set of LabVIEW functions, toolkits, and capabilities for their development activities. This is the package that DMC uses internally for development, so utilizing this package also ensures that the controller PC will have full access and compatibility with all supporting software provided by DMC.

The system includes dual DellTM UltraSharpTM U2410 monitors that are mounted above the desk surface of the enclosure via a dual flat panel mounting arm.

The system includes the Logitech Wireless Keyboard/Mouse MK710 peripheral devices for user operation of the PC.

Battery Stack Simulation

The Battery Stack Simulation sub-system consists of Pickering PXI 41-752, 6-cell battery simulator cards placed inside a PXI chassis, providing independent cell voltage simulated outputs. The Battery Simulator System includes 18 PXI cell simulator cards, enabling simulation of a battery stack of 108 cells.

The cell simulator current outputs and voltage sense lines from each card connect to a custom-built circuit board which configures the independent simulated cells into a full simulated battery stack. It also handles battery stack management and safety functions. Past this custom circuit board, the cell supply/sense lines route to a single high-density DUT connection on the front panel of the test stand.

The Pickering cell simulator cards offer no direct means of reading back their output current or voltage. As a result, the cards themselves provide no direct capability for voltage supply line leakage current measurement, or for actual cell voltage measurements.

Since these measurements are useful for the characterization and calibration of a BMS device, DMC’s Battery Simulator System provides the capability to acquire independent cell voltage and current output measurements using a high-resolution Cell Current/Voltage Measurement Module. This module consists of an active high-density relay switch matrix that enables measurement of the current flow on any cell line or of the voltage differential between any two cell lines in the battery stack. This high-resolution cell current/voltage measurement module is described in more detail later in this document.

DMC considers the Pickering 41-752 battery simulator card to be an excellent tool for simulating a battery input to a BMS for the following reasons:

1. The 750V isolation barrier allows the outputs to be stacked in series without inducing unintentional ground faults or loops and without voiding the manufacturer’s warranty.
2. The cards are capable of both sourcing and sinking current, just like an actual chemical cell. Accurate testing of BMS cell balancing operations requires this current-sinking function.

The 750V isolation barrier of the Pickering 41-752 card allows it to be used to emulate an entire low power battery stack representative of those used for vehicle propulsion.

The Pickering PXI 41-752 is a PXI based, 6-channel battery simulator module. Each channel of the module can supply up to 7V and 300mA to the load. Each channel is fully isolated from ground and from each other, allowing the channels to be connected in series to simulate batteries arranged in a stacked architecture. The 750V isolation barrier permits the 41-752 to be used to emulate a low power battery stack representative of those used for vehicle propulsion.

Each battery simulator provides independent power and sense connections, allowing the battery simulator to sense a remote load and correct for wiring voltage losses. The battery simulator is designed to respond quickly to dynamic loads, minimizing the need for local decoupling capacitors at the load.

A signal line on the user connector allows the user to shut down all battery simulator channels with a single connection. Multiple module control lines are linked together to provide an easy way of inhibiting voltage generation (E-Stop) when using many series-connected modules that provide high output voltages.

Cell Voltage/Current Measurement Module (Optional)

The Cell Voltage/Current Measurement Module provides independent (DMM based) high-resolution measurement of the voltage between any two cells in the simulated battery stack or of the current on any given cell voltage supply line. These measurements are useful for the characterization (cell balancing functions, power consumption, leakage currents, etc.) or calibration of a BMS device. This module also enables automated calibration of the Battery Stack Simulator device itself.

To deliver this extensive range of measurements in a cost-effective manner, the module utilizes a single high-accuracy digital multimeter in conjunction with an active high-density switching matrix to connect this meter to any desired set of measurement points. The Battery Simulation system contains a NI PXI-4071 Digital Multi-Meter (DMM) installed in one of the PXI chassis. This 7 ½ digit DMM delivers the following measurement capabilities:

• Voltage measurements from ±10 nV to 1000 VDC
• 8 DC current ranges with sensitivity down to 1 pA
• ±500 VDC/Vrms common-mode isolation
• Resistance measurements from 10 µΩ to 5 GΩ
• 1.8 MS/s isolated, 1000 V waveform acquisition

The Cell Voltage/Current Measurement Module uses a single DMM, and thus it is only possible to acquire one particular measurement at a given time (i.e. the specific probe point that the current relay multiplexer state is connecting the DMM to measure). It is very straightforward, however, to set up functions in the test control software to scan through all cell voltage or current measurement points by simply reconfiguring the relay state between each measurement acquired by the DMM.

The switching matrix in this module also makes it possible to simulate a broken connection between a simulated cell and the BMS or to simulate a shorted connection between two adjacent cells; these can be useful fault insertion mechanisms in BMS testing regiments. Similarly, the Voltage/Current Measurement Module also provides the ability to perform complete and total disconnection of the cell simulator from the BMS device under test.

The Cell Voltage/Current Measurement Module utilizes 5-amp relays that can handle cold switching up to 750 V and are thus more than capable of handling the expected total stack voltage generated by many simulated cells in series. 

The Cell Voltage/Current Measurement Module fundamentally consists of multiple removable/swappable relay multiplexing cards that are seated in a 4U (7”) high Vector card cabinet. It is designed to be located either directly above or directly below a PXI chassis containing cell simulator modules (as shown in the image below). Each relay card connects directly to a cell simulator card and handles the measurement multiplexing for those six simulated cells. This design makes it easy to scale the multiplexer module when adding or removing cell simulator cards to increase/decrease the size of the simulated cell stack.

Battery Stack Simulator Connections

Each simulated cell has one supply and one sense line that needs to be routed independently to the Device Under Test (to allow the cell simulator modules to accurately compensate for voltage drop in harness/wiring). Therefore, the complete set of simulated cell connections consists of 108 cell voltage supply lines and 108 cell voltage sense lines. The Battery Simulator System provides two parallel connections to the simulated cells.

Battery Stack Connection 1 is used to interface with the Device Under Test through a pair of connectors that are panel mounted in the system enclosure panel. There are separate connectors (with identical pin-out mappings for consistency) for the simulated cell voltage stack sense and supply lines, as shown below.

Battery Stack Connection 1 utilizes 2x 160 position connectors as depicted below:

Battery Stack Connection 2 provides an auxiliary parallel connection to all simulated cell supply and sense lines for external monitoring, measurement, and diagnostic purposes. This parallel connection has an available standard screw terminal connection for each cell voltage supply and sense line, as depicted below. These breakout terminal connections are mounted facing out the front of the primary system enclosure to make them externally accessible.

Temperature Sensor Simulation Module

The Temperature Sensor Simulation module supports simulation of 50x 4-bit resistive temperature. To enable future flexibility, the module provides the ability to alternatively simulate 25x 8-bit with some minor reconfiguration of built-in jumper points. The figures below illustrate the simulation of either one 8-bit or two 4-bit resistor chains and how the module supports switching from 4-bit to 8-bit simulation through the installation of jumpers. An N-bit simulated temperature sensor essentially consists of N fixed resistors that can be inserted or removed from the simulated temperature sensor circuit using a relay switching matrix. The resistor values that are placed in line with the simulated temperature sensor circuit add with one another (since they are in a series configuration) to produce the desired resistance to simulate a particular temperature reading.

For a 4-bit simulated sensor, there are a total of 2^4 = 16 discrete resistance values (including a short circuit) that can be applied by each simulated sensor. For an 8-bit simulated sensor, there are a total of 2^8 = 256 resistance values that can be generated. The actual resistor values used in the module (which thus affect the total range and the set of overall resistance values that can be generated) are fully configurable and are determined by the requirements of the test application.

The temperature sensor simulation system utilizes a modular motherboard and daughter card architecture. The actual physical resistors that comprise the simulated temperature sensors are all installed on swappable daughter cards that plug into the module’s motherboard. The motherboard handles the “infrastructure” of aggregating independent resistors into simulated temperature sensors, integrating relays to control the simulated temperature circuits, etc. By swapping in and out sets of daughter cards containing different resistor values, different types of temperature sensors or different temperature ranges can be simulated to accommodate varying testing requirements or DUT models.

The relays that are responsible for configuring the desired output state of the simulated temperature sensors are contained on and controlled by two high-density PXI relay cards. Control of the Temperature Sensor Simulation module is accomplished through a set of LabVIEW driver VIs provided along with the system.

The simulated temperature sensor module drivers include algorithms to automatically calculate the optimal combination of resistors that should be inserted into a given simulated temperature sensor circuit to achieve the closest possible resistance to the commanded value. Thus, the interface for controlling the temperature sensor module is simple and abstracts away the lower-level hardware operations. It is simply necessary to specify the desired resistance (corresponding to the temperature reading you want to simulate) to apply to a particular temperature sensor number.

Each simulated thermistor requires two connection lines, and thus for a total of 50 simulated thermistors the system has 100 total connections from the Temperature Sensor Simulation Module to the DUT. The Temperature Sensor Simulation Module has a 104-position connector mounted in the front panel of its enclosure, as depicted in the image below.

PX Chassis to Controller Interface

The Battery Simulator System includes two full 18-slot NI PXI-1045 chassis to house Cell Simulator PXI cards as well as supporting instrumentation and device control cards.

Both of these chassis interface to the controller PXI using an MXI Express interface. A NI PXI-PCIe8362 card is installed in an available PCIe port of the controller PC to provide two MXI interface ports. Each PXI chassis has a NI PXI-8360 MXI Interface card installed in the first slot of the chassis. The MXI ports on the controller PCI card each connect via an included three-meter, high-speed MXI cable to one of the MXI interface cards in the respective PXI chassis to effectively link both chassis to the single PC controller.

This MXI Express interface provides a software-transparent link between the controller PC and the PXI chassis that house system instrumentation and card modules. This linkage allows the Battery Simulator hardware to effectively be available as native or directly connected instrumentation on the controller computer.

Software Driver Libraries for System Control

The Battery Simulator System includes LabVIEW driver libraries (with full unlocked source code) that provide full control over the available functionalities of the Battery Simulator System. DMC did not develop a higher-level test execution control application for this particular system, as the customer wished to develop a primary test control application internally.

DMC has provided the following control drivers (with accompanying documentation) for use on the controller PC:

• DMC custom LabVIEW drivers for full simulated battery stack control and management
• DMC custom LabVIEW drivers for control of Cell Voltage/Current Measurement Module
• DMC custom LabVIEW drivers for control/management of simulated temperature sensors
• DMC custom LabVIEW Digital Multi-Meter Drivers for higher-level DMM functions (waveform capture and analysis, etc.)
• VISA (Virtual Instrument Software Architecture) driver set for direct control of individual Cell Simulator modules and Pickering relay cards
• Direct IO driver set for direct control of individual Cell Simulator modules and Pickering relay cards

Safety/Interlock Functions

Since the Battery Simulator System can generate high voltages (as required for battery stack simulation), it contains both hardware and software-based safety features to disable all voltage output during a safety event.

• Large Red ESTOP button in the middle of the top desk surface of Battery Simulator System enclosure
• External/Remote Interlock connector on the right-side panel of the enclosure
• Software-based disable command to open PC-controlled relay that is in series with safety interlock loop

Activating any of these safety features will immediately turn off all voltage outputs from the Battery Stack Simulator.

Company Overview And Qualifications

DMC is a well-known and established controls engineering and consulting firm focused on the industrial automation market. We develop and implement solutions for a wide range of industries using a variety of technologies. DMC has successfully delivered solutions for hundreds of companies including 3M, Abbott Laboratories, Argonne National Labs, Bosch, BRP, Caterpillar, Chrysler, Fermilab, Ford, John Deere, UL, Wrigley, and Yaskawa. Every solution we develop is based on a solid understanding of engineering principles with the primary objective of helping our client increase profitability and productivity using world-class solutions.

DMC is a certified member of the Control Systems Integrators Association (CSIA). DMC passed a rigorous third-party audit of 200 criteria that span all aspects of business performance in the areas of:

• General Management
• Human Resources Management
• Marketing and Business Development
• Financial Management
• Project Management
• System Development Lifecycle
• Quality Assurance Management

National Instruments / LabVIEW Experience

DMC has been a National Instruments (NI) Alliance member for more than 10 years with one of the largest teams of Certified LabVIEW developers in the country, including several National Instruments Certified LabVIEW Architects (highest level of certification available), and multiple NI Certified LabVIEW Developers.

Test and Measurement Experience

Our Test and Measurement Automation services help clients automate laboratory testing using the latest technologies. We have years of experience delivering world-class solutions to leaders in research, development, production, quality, and certification testing. Our flexible and collaborative approach is proven to deliver efficient, accurate, and robust test systems, as well as the tools to leverage test data for effective results analysis.

DMC has employed LabVIEW in many industries, including product development, test and measurement engineering, R&D, and high-tech manufacturing. We have developed LabVIEW solutions for hundreds of projects at dozens of customers, including:

• Argonne National Laboratories
• Fermi National Accelerator Laboratory (Fermilab)
• Bombardier Recreational Products Bosch
• Underwriters Laboratories
• LG
• Bosch

DMC applies a disciplined and systematic approach to LabVIEW software design. Engineers at DMC employ software conventions and architectures so that code is structured and well-organized. One example of these structures is a LabVIEW state machine that builds a system based on states, events, and actions

DMC has a vast, reliable code library that has been tested and can be used to significantly reduce the development time and risk. Leverage the work we’ve already done to reduce start-up time now and downtime later. We’ve also developed LabVIEW tools for additional features such as HTML and PDF reporting, TDMS file storage, external data viewers, and SQL databases.

The post NASA Battery Simulator System appeared first on DMC, Inc..

Implementing an automated end-of-line testing system offers even more benefits to manufacturers. Automated EOL testing can impact the production line by improving test efficiency, identifying issues with product quality, and minimizing defects and downtime.

Benefits of Automating End-of-Line Testing

From identifying defects in production to collecting and analyzing data on the production process, automating end-of-line testing equipment offers many advantages to manufacturers.

Consistency and Accuracy

Automating EOL testing ensures consistent and accurate quality control across production runs. An automated end-of-line testing system performs a comprehensive test on each product that comes off the line using precise tools and standardized procedures. Automating this testing ensures that the quality control process remains consistent and that any defects are accurately identified.

Limiting the operator’s interaction on the testing process leads to more efficient and reliable production. With automated end-of-line testing equipment, less operator interaction means fewer sources for error.

Data Collection and Analysis

Another advantage of automating your end-of-line testing system is having access to a record of complex test data. Automated EOL testing systems can collect data on your production lines and analyze it to identify issues and patterns.

Accessing the vast amount of data automatically collected by the EOL test system, users can generate a variety of reports. Manufacturers can identify trends and pinpoint potential issues in real-time. This statistical process control and ongoing monitoring can help manufacturers establish ways to continue improving their production lines.

Enhanced Product Quality

An automated EOL testing system thoroughly puts each product on the line through a series of tests to verify that the product meets its design and functionality standards. With a consistent process for testing each product that is not subject to human error, an automated end-of-line testing system can identify defects quickly.

By pinpointing any potential product issues, EOL testing helps manufacturers ensure that only high-quality products that meet their standards reach the market. This attention to consistency and quality when delivering products can positively impact customer satisfaction and the manufacturer’s brand reputation. Customers will know what to expect when interacting with that product or brand.

Efficiency and Speed

It’s no surprise that automated end-of-line testing is quicker and more efficient than manual testing. By reducing the risk of human error, the automated EOL test system consistently performs the same testing cycle at a faster pace. This is especially beneficial for repetitive tests and extensive test cycles.

Utilizing an automated end-of-line test system reduces the amount of human effort needed to set up the test and the expertise required to operate it. Automated test systems can quickly detect product or production issues, reducing downtime.

Cost Reduction

While automating your end-of-line testing equipment requires an initial investment of money and time to set it up, it can save you money in the long run. Reducing the dependency on human operators can lessen your labor costs. With an automated EOL testing system to quickly identify issues, your production line will experience fewer errors and downtime, leading to long-term cost savings. Over time, you’ll realize the ROI of streamlined operations, improved product quality, and lower operational costs.

Key Technologies and Methodologies in Automated End-of-Line Testing

Automated end-of-line testing utilizes a variety of technologies to streamline testing, collect data, and analyze data to improve operations.

Data Acquisition and Analysis

One of the most valuable aspects of an automated end-of-line testing system is the ability to automatically collect data and analyze it to identify patterns. By analyzing data in real-time during end-of-line testing, manufacturers can immediately detect potential issues and correct them, leading to reduced downtime and improved operational efficiency.

DMC has deep expertise in integrating high-speed data acquisition systems with automated test equipment. We can implement an automated testing system that collects data from disparate sources and large channel-count systems, securely stores it, and displays the data.

Using the NI LabVIEW programming environment, our systems can automatically process and visualize your data. LabVIEW is a graphical programming environment, and its data visualization tools offer real-time monitoring and control of testing processes. This automated approach to end-of-line testing speeds up the decision-making process with real-time data and results in more accurate and efficient testing.

Programmable Logic Controllers (PLCs)

Programmable Logic Controllers (PLCs) can be used to help automate test processes by offering precision control of the test equipment. By integrating with various components, PLCs can improve test operation and reliability.

DMC has extensive experience programming PLCs for end-of-line testing and connecting PLCs to LabVIEW. Many operations that are controlled by PLCs require a more powerful data acquisition controller for complex algorithms or large data arrays. DMC has implemented solutions connecting PLCs to LabVIEW on Windows and Real-Time targets for applications needing high-speed data acquisition and complicated processing for end-of-line testing.

Our custom PLC programming expertise integrates with Automated Test Equipment (ATE) to optimize test processes and ensure accuracy. PLCs can coordinate ATE components and automate test operations, streamlining the test process and improving accuracy.

Custom Test Stand Design

There is not always a one-size-fits-all solution for automated test systems. End-of-line testing systems may be needed in rugged environments or require connecting disparate sources. Fortunately, there are many options to customize test stands that meet specific testing requirements.

DMC’s has deep experience in designing and fabricating custom test stands for various industries. Our services range from defining test requirements and designing the test stand architecture to developing the test automation software and designing custom PCBs for test interface signal routing. We can support you through the life cycle of the automated test stand, from integrating DAQ systems to validation and documentation, and ongoing support.

Whether you need a simple stand-alone controller or a facility-wide, customized testing system, our automated test stand designs will enhance your end-of-line testing capabilities. We have experience in designing and developing portable and modular test stands for testing in the field as well as integrating multiple locations as well as creating turnkey test stands.

Vision Inspection Systems

Vision inspection systems are another technology used in automated end-of-line testing that helps enhance accuracy in detecting defects and ensure product quality. Using advanced cameras, these systems can inspect products in the manufacturing at a level of detail that a human operator might miss. Vision systems streamline testing and guarantee the quality of products that make it off the production line to customers.

Many industries can benefit from utilizing vision inspection tools in end-of-line testing systems. Automotive production lines use vision systems to inspect components and ensure that they meet safety standards. The food and beverage and pharmaceutical industries use vision inspection systems to inspect their packaging and labels. In electronics manufacturing, vision inspection helps ensure product quality so that only products that meet standards become available to consumers.

DMC has more than 15 years of experience in creating robust vision inspection systems with a wide variety of vision inspection platforms, particularly the National Instruments (NI) platform. Many of our vision applications utilize NI LabVIEW for its ability to analyze and present data. As an NI Vision Specialty Partner, we are a recognized leader in providing vision inspection systems and software. Using our vision lab, we can optimize your system or determine the best solution for your potential application by specifying the ideal lighting, hardware, and software.

Industry Applications and Case Studies

DMC has experience automating end-of-line testing across a variety of industries and applications.

Automotive Industry

Automated end-of-line testing improves safety and reliability in automotive manufacturing. DMC can help enhance your automotive test capabilities from R&D and product development to validation, production, and quality testing. We’ve delivered successful automotive solutions including EV/battery test, vehicle electronics, powertrain, and infotainment as well as enterprise data management, test assets, and cloud-based storage and presentation.

For example, DMC developed a new end-of-line test station for a manufacturing line producing automotive sensors that programs and tests a variety of parts. Our automated end-of-line testing system reduced production time and costs, improved test accuracy, and identified common failure modes through tracking and analysis.

Battery and Clean Energy Industry

Automated test systems ensure the reliability and safety of battery packs and battery management system (BMS) in the energy industry. DMC can design, build, and program automated testing and validation systems for battery pack and battery management systems. Our modular test platform creates systems customized to the end user’s specifications. DMC’s custom test solutions ensure precise and reliable battery pack and BMS testing, resulting in optimal performance and safety.

The DMC Battery Production Test (BPT) System is a fully automated test solution with a modular design to meet the needs of battery production test regimens. The BPT System’s capabilities include assembly and electrical verification tests, BMS verification tests, and power capability tests.

Consumer Products

End-of-line testing is critical in ensuring the functionality and durability of electronics and other consumer products. DMC has worked with major manufacturers to design and develop automated test systems for appliances and electronics.

In one instance, DMC worked with a manufacturer of consumer products to develop a turnkey appliance test lab. The solution included multiple custom-designed test stands to conduct tests on consumer products like dishwashers, microwaves, refrigerators, and more. The rugged systems allowed for week-long uninterrupted tests with easily searchable test data stored in a centralized location.

Medical Devices

Automated testing is a vital part of verifying compliance and safety in medical manufacturing. At DMC, we’ve worked with medical and pharmaceutical manufacturers to enhance test capabilities like end-of-line testing, vision inspection, rapid prototyping, thermal camera integration, high-speed testing, and flow rate or particulate measurement.

One of our medical solutions involved developing a vision system capable of inspecting a pharmaceutical product and the text on its packaging. It was crucial for DMC to meet the demands of the high-speed packaging line while ensuring the correct product size, identification, and labeling. Our solution inspected 100% of products and rejected products that didn’t meet quality standards, increased production yield, and allowed for the inspection of various products.

Aerospace and Defense

Rigorous testing is imperative to validate the quality of the aerospace and defense industry‘s mission-critical systems. DMC’s custom equipment spans all test domains from R&D through production. Our test system specialties include aircraft sensors, aircraft tires and landing gear, battery and energy storage systems, and communications protocols.

On one aerospace project, DMC worked with Arrow Science and Technology to develop a LabVIEW tester application that validates Power Bolt Nut Assemblies (PBNAs) that help attach cargo modules onto the International Space Station (ISS). DMC’s solution can test up to four assemblies in parallel using high-speed data acquisition. It offers configurable test parameters and a user-friendly HMI that allows operators to view and log test data.

Why Partner with DMC

DMC’s Industrial Automation division is a key benefit to partnering with DMC on implementing automated test systems. Our experience in manufacturing automation and system integration services for the industry ensures that our end-of-line test systems are designed with deep knowledge of how they fit into the broader production process and facility.

Our industrial automation services include interfacing factory lines with intelligent systems like Manufacturing Execution Systems, recipe management systems, SCADA systems. Reporting and productivity monitoring systems, and more. This industrial automation expertise is a valuable complement to DMC’s production test systems.

Custom Solutions for Specific Needs

DMC can work alongside your team collaborating to develop tailored automated test systems based on your specific requirements or develop a custom turnkey system. These automated test systems ensure consistency, accuracy, and reliability in product testing.

By leveraging DMC’s custom test solutions, manufacturers can achieve enhanced product quality, faster testing cycles, and reduced costs. Harnessing the real-time data captured by automated test systems allows manufacturers to pinpoint issues in production, streamline operations, and minimize expenses.

Expertise and Experience

Founded in 1996, DMC is a NI Preferred System Integrator and project-based engineering firm with nearly 300 employees and 15 locations across the US. As test and measurement automation experts, we design and deliver solutions for our customers around the world.

Our capabilities span from supporting your test system throughout the project life cycle to developing a turnkey test stand. We have engineers with extensive experience using a range of programming platforms, including LabVIEW, TestStand, and text-based languages, to meet our client’s needs.

The post What are the Benefits of Automated Test Systems for End-of-Line Testing? appeared first on DMC, Inc..

In addition to attending the event, we are proud to partner with National Instruments (NI) on a presentation.

Presentation Information

Innovate, Validate, Elevate: LabVIEW Quality Paradigm 
Speaker: Kevin Shirey, Senior Project Engineer, DMC
Date: July 25 at 2 p.m.
Duration: 50 minutes 

With over 20 years of experience using LabVIEW, Kevin Shirey, Senior Project Engineer on DMC’s Test & Measurement team, Certified LabVIEW Architect, and LabVIEW Champion will be presenting at this year’s conference. 

“Being a LabVIEW champion is about celebrating your community, being able to provide a lot of value, and helping advance the community and understanding for LabVIEW,” Shirey said.

If you’re ready to revolutionize your LabVIEW development approach, elevate your code to new heights, and discover how coding guidelines and National Instruments’ Center of Excellence principles set the stage for innovation and excellence in LabVIEW development, this presentation is for you. 

“Innovating higher quality processes involves fostering a collaborative environment where developers actively engage in iterative feedback loops,” Shirey said. “By encouraging open communication and embracing diverse perspectives during code reviews, we elevate the overall code quality. This holistic approach not only expedites software delivery but also establishes a culture of continuous improvement, where innovation and collaboration intersect for fast and effective higher quality code.” 

Conference Information

When: July 23, 2024 – July 25, 2024 
Where: The Buffalo Rose in Golden, Colorado 
Register for tickets here

DMC and NI

DMC has worked closely with NI for more than 25 years. As an NI Preferred System Integrator and one of 12 teams recognized as a Certified Center of Excellence, DMC looks forward to this opportunity to connect other users and stay up to date on the latest developments in NI hardware and software.

The post Join DMC at GDevCon North America appeared first on DMC, Inc..

Electric vehicles are bringing new test and validation challenges to the automotive industry as the electronic and software content of the vehicles grows. In this blog, I discuss the basics of electric vehicle battery pack designs and some of the tests that should be performed on them in a manufacturing environment. I’ll also show you how the DMC Battery Testing Platform can help solve these complex testing problems.

Table of Contents

• The Motivation for EV Battery Testing
• Inside an EV Battery Pack
• Inside an EV Battery Management System (BMS)
• BMS Topology
• BMS State of Charge Calculation
• BMS Cell Balancing Functions
• State of Health and Diagnostics
• BMS Communications
• Testing an EV Battery Pack
• BMS Development Testing
• Pack Development Testing
• Module Production Testing
• Pack Production Testing
• EV Battery Pack Testing Solutions
• Off the Shelf Testing Solutions
• Arguments for a Customized, Modular Test System Approach
• The DMC Battery Testing Platform
• Hardware System Description
• Software System Description
• Example System – BMS Validation Testing
• BMS Simulated Inputs
• BMS Output/Functional Monitoring
• Common Test Routines
• Example System – End of Line Functional Testing

The Motivation for EV Battery Testing

Return to the Table of Contents

The battery packs used as the rechargeable electrical storage system (RESS) in electric vehicles (EVs), hybrid electric vehicles (HEVs), and plug-in hybrid electric vehicles (PHEVs) are large and complex. Controlled release of the battery’s energy provides useful electrical power in the form of current and voltage. Uncontrolled release of this energy can result in dangerous situations such as the release of toxic materials (e.g., smoke), fire, high-pressure events (i.e., explosions), or any combination thereof.

Severe physical abuse, such as crushing, puncturing, or burning, can cause uncontrolled energy releases, but mechanical safety systems and proper physical design can mitigate this. However, shorted cells, abnormally high discharge rate, excessive heat buildup, overcharging, or constant recharging can also cause this which can weaken the battery. These causes are best prevented by a properly designed and validated electronic safety and monitoring system, better known as a battery management system (BMS).

One of the significant validation and safety challenges to be tackled in modern EVs, HEVs, and PHEVs concerns the effective testing of the battery pack itself and the battery management systems (BMS) – the complex electronic system that manages the performance and safety of the battery pack and the high levels of electrical energy stored within. In the sections below, I will describe both the battery pack and the BMS in greater detail.

Inside an EV Battery Pack

Return to the Table of Contents

Battery pack designs for EVs are complex and vary widely by manufacturer and specific application. However, they all incorporate combinations of several simple mechanical and electrical component systems which perform the basic required functions of the pack.

Cells and Modules

Battery cells can have different chemistries, physical shapes, and sizes as preferred by various pack manufacturers. However, the battery pack will always incorporate many discrete cells connected in series and parallel to achieve the total voltage and current requirements of the pack. In fact, battery packs for all-electric drive EVs can contain several hundred individual cells.

Smaller stacks, called modules, typically consist of the large stack cells to assist in manufacturing and assembly. Several of these modules will be placed into a single battery pack. Within each module, the cells are welded together to complete the electrical path for current flow. Modules can also incorporate cooling mechanisms, temperature monitors, and other devices. In most cases, these modules also allow for monitoring the voltage produced by each battery cell in the stack by the BMS.

Safety Components and Contractors

Somewhere in the middle, or at the ends, of the battery cell stack is a main fuse which limits the current of the pack under a short circuit condition. Also located somewhere within the electrical path of the battery stack is a “service plug” or “service disconnect” which can be removed to split the battery stack into two electrically isolated halves. With the service plug removed, the exposed main terminals of the battery present reduced electrical danger to service technicians. Often, a high voltage interlock circuit will run throughout key elements and connection points of the pack to establish hard-wired safety functions.

The battery pack also contains relays, or contactors, which control the distribution of the battery pack’s electrical power to the output terminals. In most cases, there will be a minimum of two main relays which connect the battery cell stack to the main positive and negative output terminals of the pack, supplying high current to the electrical drive motor. Some pack designs will include alternate current paths for pre-charging the drive system through a pre-charge resistor or for powering auxiliary busses which will also have their own associated control relays. For obvious safety reasons, these relays are all ordinarily open.

Temperature, Voltage, and Current Sensors

The battery pack also contains a variety of temperature, voltage, and current sensors. The pack will include at least one main current sensor which measures the current being supplied by (or sourced to) the pack. The current from this sensor can be integrated to track the actual state of charge (SoC) of the battery pack. The state of charge is the pack capacity expressed as a percentage and serves as the pack’s fuel gauge indicator. The battery pack will also have a main voltage sensor for monitoring the voltage of the entire stack and a series of temperature sensors, such as thermistors, located at key measurement points inside the pack.

Collection of data from the pack sensors and activation of the pack relays are accomplished by the pack’s battery monitoring unit (BMU) or battery management system (BMS). The BMS is also responsible for communications with the world outside the battery pack and performing other key functions, as described in the following section.

Inside an EV Battery Management System (BMS)

Return to the Table of Contents

The BMS controls almost all electronic functions of the EV battery pack, including battery pack voltage and current monitoring, individual cell voltage measurements, cell balancing routines, pack state of charge calculations, cell temperature and health monitoring, ensuring overall pack safety and optimal performance, and communicating with the vehicle engine control unit (ECU).

In a nutshell, the BMS must-read voltages and temperatures from the cell stack and inputs from associated temperature, current and voltage sensors. From there, the BMS must process the inputs, making logical decisions to control pack performance and safety, and reporting input status and operating state through a variety of analog, digital, and communication outputs.

BMS Topology

Return to the Table of Contents

Modern BMS systems for PHEV applications are typically distributed electronic systems. In a standard distributed topology, routing of wires to individual cells is minimized by breaking the BMS functions up into at least two categories. The monitoring of the temperature and voltage of individual cells is done by a BMS “sub-module’ or “slave’ circuit board, which is mounted directly on each battery module stack. The BMS “main module’ or “master’ perform higher-level functions such as computing the state of charge, activating contactors, etc. along with aggregating the data from the sub-modules and communicating with the ECU.

The sub-modules and main module communicate on an internal data bus such as CAN (Controller Area Network). Power for the BMS can be supplied by the battery stack itself, or from an external primary battery such as a standard 12V lead-acid battery. In some cases, the main module is powered externally, while the sub-modules are powered parasitically from the battery modules to which they are attached.

BMS State of Charge Calculation

Return to the Table of Contents

The BMS is responsible for tracking a battery pack’s exact state of charge (SoC). The SoC may be tracked to provide the driver with an indication of the capacity left in the battery (fuel gauging), or for more advanced control features.

For example, SoC information is critical to estimating and maintaining the pack’s usable lifetime. Usable battery life can be reduced dramatically by charging the pack too much or discharging it too deeply. The BMS must maintain the cells within the safe operating limits. The SoC indication is also used to determine the end of the charging and discharging cycles.

To measure SoC, the BMS must include a very accurate charge estimator. Since you can’t directly measure a battery’s charge, the SoC is calculated based upon other measured characteristics like the voltage, temperature, current, and other proprietary parameters (depending on the manufacturer). The BMS is the system responsible for these measurements and calculations.

BMS Cell Balancing Functions

Return to the Table of Contents

The BMS must compensate for any underperforming cells in a module, or “stack,’ by actively monitoring and balancing each cell’s SoC. In multi-cell battery chains, small differences between cells (as a result of production tolerances, uneven temperature distribution, intrinsic impedance, and/or aging characteristics) tend to be magnified with each charge and discharge cycle. In PHEV applications the number of cycles can be very high due to the use of regenerative braking mechanisms.

Assume degraded cells with a diminished capacity existed within the battery stack. During the charging cycle, there is a danger that once the pack has reached its full charge, it will be subject to overcharging until the rest of the cells in the chain reach their full charge. As a result, temperature and pressure may build up and possibly damage that cell. During discharging, the weakest cell will have the greatest depth of discharge and will tend to fail before the others. The voltage on the weaker cells could even become reversed as they become fully discharged before the rest of the cells resulting in early failure of the cell.

Cell balancing is a proactive way of compensating for weaker cells by equalizing the charge on all the cells in the chain and thus extending the battery pack’s usable life. During cell balancing, circuits are enabled which can transfer charge selectively from neighboring cells, or the entire pack, to any undercharged cells detected in the stack.

To determine when active cell balancing should be triggered, and on which target cells, the BMS must be able to measure the voltage of each cell. Moreover, each cell must be equipped with an active balancing circuit.

State of Health and Diagnostics

Return to the Table of Contents

The State of Health (SoH) is a measure of a battery’s capability to safely deliver its specified output. This metric is vital for assessing the readiness of the automobile and as an indicator of required maintenance.

SoH metrics can be as simple as monitoring and storing the battery’s history using parameters such as the number of cycles, maximum and minimum voltages and temperatures, and maximum charging and discharging currents (which can be used for subsequent evaluation). This recorded history can be used to determine whether it has been subject to abuse, which can be an important tool in assessing warranty claims.

More advanced measures of battery SoH can include features such as automated measurement of the pack’s isolation resistance. In this case, specialized circuits inside the battery pack can measure the electrical isolation of the high current path from the battery pack ground planes. Such a safety system could preemptively alert the operator or maintenance technicians to potential exposure to high voltage.

BMS Communications

Return to the Table of Contents

Most BMS systems incorporate some form of communication with the world outside the battery pack, including the ECU, the charger controller, and/or your test equipment. Communication interfaces are also used to modify the BMS control parameters and for diagnostic information retrieval.

The most common communication bus in automotive applications is CAN, although Automotive Ethernet, RS232 / RS485 serial, SPI, TCP/IP, or other networks could be used. CAN networks come in a variety of implementations and can include a range of higher-level “application layer” protocols like Unified Diagnostic Services, OBD II, J1939, etc.

Aside from a digital bus, separate analog and/or digital inputs and outputs should be considered as supplemental parts of BMS interface and communication. Discrete inputs and outputs can be used for redundancy and for operations requiring a separate interface such as activating an external contactor, fan, or dashboard lamp.

Testing an EV Battery Pack

Return to the Table of Contents

Developing a test strategy for an assembly as large, complex, and powerful as an EV battery pack can be a daunting task. Like most complex problems, breaking the process down into manageable pieces is the key to finding a solution. Accordingly, testing only at carefully selected points in the development and manufacturing process will reduce the effort required.

These key points for many pack manufacturers include BMS development, pack development, module production, and pack production. The tests performed at each step depends on the specifics of the process and the device and is a different matter altogether.

BMS Development Testing

Return to the Table of Contents

During BMS development, engineers need a way to reliably test the BMS under real-world conditions to complete their verification and validation plans. At this stage, test strategies such as Hardware-in-the-Loop (HiL) testing are often performed. HiL testing involves simulating physical inputs and external connections to the pack while monitoring its outputs and behavior relative to design requirements.

Accurately simulating all the conditions to which a BMS may be subjected during real-world operation is not easy. However, one must consider the long-term cost of skipping testing over a full range of conditions, remembering that any given condition could lead to a critical failure in the field. In the end, simulating nearly every combination of cell voltages, temperatures, and currents you expect your BMS to encounter is really the only way to verify that your BMS reacts as you intended to keep your pack safe and reliable.

Pack Development Testing

Return to the Table of Contents

At the Pack Development stage, engineers are typically concerned about testing the entire assembly through various types of environmental stress testing as part of design validation or product validation plans. Environmental stress could include exposure to temperature extremes, thermal shock cycling, vibration, humidity, on-off cycling, charge / discharge cycling, or any combination of these. The testing requirements here typically include performing a full batch of performance tests on a pack both before and after application of the stress. Live monitoring of the pack throughout the environmental stress period may also be required.

Module Production Testing

Return to the Table of Contents

Requirements for Module-level testing vary widely depending on the actual design of the system. The main testing to be done at this point involves a simple charge / discharge test to ensure that connections between cells are robust and can handle the intended current loads without failing or shedding excessive heat. Further testing could involve ensuring the cell voltages are reported correctly, that the cells are balanced, and/or that the cooling and temperature monitoring sensors are working properly.

Pack Production Testing

Return to the Table of Contents

Pack Level testing is typically done at the “End of Line” (EOL) stage, as pack assembly is nearing completion or is fully completed. At this stage, the pack must complete a full batch of tests to ensure the proper functioning of every major pack subsystem (functional testing). These tests include simple pinout and continuity checks, confirming proper relay operation, testing functionality of safety devices such as high voltage interlocks, carefully measuring the isolation resistance under high potential (hi-pot testing), and testing proper communications and operation of the BMS.

After EOL functional testing is completed, packs may also be subjected to charge / discharge cycling and drive profile cycling, which will simulate the typical conditions the pack will see when integrated into the EV drivetrain. Packs can also be run through active cell balancing routines to set the initial charge state of each cell to a nominal condition, or to set the pack SoC to a level appropriate for shipping and storage.

EV Battery Pack Testing Solutions

Return to the Table of Contents

Once you have decided where you are testing, and what you are testing, you need to determine how you will be testing. Since every battery pack design has unique elements, and since testing requirements vary accordingly based on agreements between the manufacturer and end-user, in reality, there is no one-size-fits-all solution for everyone’s battery pack testing needs.

Off the Shelf Testing Solutions

Return to the Table of Contents

Some portions of the testing, such as charge / discharge / drive cycle evaluation in specific, are standardized. As such, pre-packaged, off-the-shelf hardware and software solutions exist for these particular test steps. These systems make use of the only elements common to every battery pack: the positive and negative output terminals. These turn-key systems may even allow you to add in options required to test components and functions specific to your battery pack, such as CAN communications, external relay activation, etc.

When considering off-the-shelf systems for use in your test plan, make sure to ask yourself these three basic questions:

1. Are you getting everything you need just the way you want it… or are you settling for what the other guy needed?
2. Are you using everything you are going to pay for… or are you paying for the things you won’t use?
3. Is it flexible enough to accommodate your future needs… but not so flexible that it becomes cumbersome to use?

Arguments for a Customized, Modular Test System Approach

Return to the Table of Contents

Building a functional test system tailored to your battery pack and your specific testing needs often sounds like a more costly and time-consuming approach, and it can be. However, the route you take to achieve that end goal makes a world of difference in the outcome and long term ROI.

Choosing modular hardware and software testing platform that can be tailored to meet your requirements can be used to jump-start this approach, making it a very viable option. This is especially true if the platform you choose leverages proven commercial technologies and open industry standards.

In the end, this modular platform based testing approach can have several benefits:

1. It can dramatically lower the cost of the test system, both in initial capital expenditure and in the overall cost of ownership, through the use of commercial technologies and standards.
2. It can increase your test throughput with fast measurement hardware and software capable of managing multiple test routines in parallel.
3. The time required to redesign test systems for new products will decrease through the use of flexible, modular software and hardware.
4. You can get exactly what you need, the way you want it. You can get everything you paid for, and your text station will be flexible, without being cumbersome to use.

The DMC Battery Testing Platform

Return to the Table of Contents

The DMC Battery Testing Platform is specifically designed for testing entire battery packs, battery modules, and BMS components for EV, HEV, PHEV, and charger manufacturers, suppliers, and third-party testing facilities. This platform delivers completely automated test systems specifically designed for EOL manufacturing tests, BMS validation and verification, and environmental lifecycle testing / monitoring.

DMC’s modular Battery Testing Platform incorporates proven software and hardware architectures, along with flexible and reliable subsystem components, which can be completely customized to the end user’s specifications.

The Battery Testing Platform is built around high-quality COTS (commercial off the shelf) hardware assembled from a variety of vendors, including National Instruments (NI) and Pickering Interfaces, among others. Selection of individual instruments in the DMC system is based entirely on the required performance. This strict attention to specifications and performance provides DMC battery test system users with best in class performance.

Hardware System Description

Return to the Table of Contents

The DMC Battery Testing Platform leverages a modular hardware architecture, flexible subsystem components, and reliable instrumentation, to create completely customized test systems tailored to meet the end user’s specifications. Use of the modular platform allows the production of a battery test system carefully configured to each customer’s needs, with the performance and cost of a turn-key, off-the-shelf solution.

The image on the right shows the basic block diagram of a test system. Each test system produced will include only the modules required to meet end user’s specifications. Modules can be easily customized, or new ones added, as needed for your implementation.

Core system instrumentation and hardware include:

• NI Modular Instrumentation Chassis (PXI or CompactDAQ) with NI Embedded System Controller
• Low Voltage Programmable DC Power Supplies
  • High-Resolution Digital Multimeters and LCR Meters for Precise Voltage, Current, Resistance, Capacitance, Inductance Measurement
• High Voltage, High-Density Switching / Multiplexing Modules
• NI XNET CAN Ports (High Speed, Low Speed, CAN FD) with Selectable Termination
• High-Speed Simultaneous Sampling Analog and Digital I/O DAQ Cards
• Other instruments (hi-pot meters, Ground Bond testers, etc.)
• Integration with industry-standard Cyclers (high-power DC integrated supply and load voltage)

Software System Description

Return to the Table of Contents

DMC’s modular Battery Testing Platform solutions run proven and flexible software architectures built using National Instruments’ LabVIEW Development System platform. DMC builds the test software with several audiences in mind.

1. Engineers are provided with password-protected access to the following: test settings, system parameters, a fully interactive “manual mode” which provides on-demand access to all instruments and subsystems, and to all system self-test and diagnostic routines.
    
2. The maintenance staff has full access to an embedded calibration toolset.
    
3. Operators and technicians can load test sequences and recipes, enter extended DUT information, start tests with a single button press, monitor ongoing tests on the live data screen, and view final data reports.
    
4. Managers have access to usability statistics, error reports and logs, and can be emailed on test completion failures, and/or system trouble.

Example System – BMS Validation Testing

Return to the Table of Contents

Effectively testing a BMS system involves two primary functions:

1. Accurately simulating the required sensors and battery cell stack inputs to the BMS
2. Measuring, collecting, and processing the digital and analog outputs produced by the BMS system as a result of those inputs

DMC’s modular Battery Testing Platform solution can be configured specifically for testing your entire BMS, or individual components of the system. Of course, your specific requirements may vary, but a common BMS testing solution might have the following physical requirements:

BMS Simulated Inputs

Return to the Table of Contents

• Simulate a Fully Adjustable, 100+ Cell Battery Stack
• Simulate 50+ Pack Temperature Sensors
• Simulate Various Analog Current and Voltage Sensors
• Simulate Several Pack Contactors/Relays
• Simulate Drive Motor’s Impedance Model, or Interface with a Power Inverter
• Simulate BMS External, Low Voltage Power Supply / Backup Battery

BMS Output/Functional Monitoring

Return to the Table of Contents

• Overvoltage and Undervoltage Protection Analog Output Signals
• Cell Balancing RMS Current Draw and I/V Waveform Capture
• In-Rush, Parasitic, Sleep, and Wake Current Monitoring
• Cell Voltage and Stack Voltage Accuracy Measurements
• Temperature Sensor Accuracy Measurements
• System Communications Performance (CAN, Serial, etc.)
• Safety System and Fault Condition Recognition

Common Test Routines

Return to the Table of Contents

The example BMS testing system can be configured to run the following test sequences:

• (CAN) Communication / Reporting Test: Cell Voltages, Cell Temperatures, S.O.C., Pack Current, etc.
• BMS Sensor Accuracy Test: Cell Voltage, Temperature, Pack Current
• Overvoltage and Undervoltage Protection Test
• Terminal Resistance / Capacitance / Diode Tests
• Wakeup / Shutdown Process Validation
• Current Draw Tests: Inrush, Parasitic, Sleep Current, Wake Current
• Contactor Control Validation
• High Voltage Interlock Fault Response
• Hipot Isolation (DC / AC)
• Active BMS Isolation Fault Detection
• Cell Balancing Test: Current Draw and I/V Waveform Capture
• Crash Event Response
• Diagnostics Validation (DTC Reporting + Fault Injection, Firmware Version Checks, etc.)
• Pack Peripheral Tests: Pumps, Fans, Valves, LEDs / Indicators, etc.

In addition to the core platform hardware components listed previously, the BMS test stand includes a major hardware assembly which can simulate the series stack of approximately 100 Li-ion cells comprising the actual battery to be connected to the BMS.

This functionality allows users to simulate nominal, out of the norm, and worst-case battery stack conditions, which could not be produced repeatedly, reliably, or safely with a normal chemical battery cell. As a result, the system can be used to measure live waveform captures of the currents and voltages produced by the stack under varying BMS conditions. With this information, end users can gain unique and valuable insights into the real-world operation of their BMS system.

The modular, flexible, and open nature of the DMC Battery Testing Platform solution makes selection, integration, and use of the battery stack simulator component simple and straightforward.

For more information and an example of this system configuration, see this DMC case study.

Example System – End of Line Functional Testing

Return to the Table of Contents

DMC’s modular Battery Testing Platform solution can also be configured specifically for automated end-of-line testing of your entire battery pack, including battery cycler control for charge / discharge / drive-cycle testing.

Your specific requirements will be different, but the example EOL battery pack test system can be configured to run the following test sequences:

• Pack Connection Check
• Chassis Ground Isolation Resistance
  • Direct DC V method (to 1kV)
  • USA DOT Federal Motor Vehicle Safety Standard (FMVSS) 305
  • UN ECE 324 Regulation 100
  • Proprietary / Other Methods
• High Voltage / Low Voltage Terminal Isolation Resistance
• Terminal-to-Terminal Resistance and Capacitance Checks
• Contactor Characterizations
  • Opening / Closing Timing, Voltage, and Current
• Fuse Path Validation
• High Voltage Interlock, Service Disconnect, Safety System Performance
• BMS Validation Tests
  • Sleep / Wake Mode Current Measurement
  • Activate / Deactivate Timing and Voltage
  • CAN Communications Check
• Low / High Voltage Performance
• Voltage Reporting Accuracy Validation
• Operating Power Dropout Sensitivity
• Active Isolation Capability
• Cell Balancing Capability and Characterization
• CAN Communications Checks
  • Cell, Module, and Pack Voltages
  • Pack Current
  • Pack State of Charge (SoC)
  • Cell, Module, and Pack Temperatures
  • Diagnostic Trouble and Fault Codes
  • BMS Software Version Validation
• Battery Pack High Power (Cycling) Tests
  • Max / Min Current Validation (Pulse Test)
  • DC Internal Resistance Measurement
  • Drive Cycle Performance
  • Fuse Performance
  • Charger Interface and Charge Cycle Validation
  • Power Inverter Testing
    • Including Active Load Emulation of Permanent Magnet or Induction AC Motor

For more information on this system configuration, see this DMC Case Study.

Learn more about DMC’s expertise in battery pack and BMS test systems and contact us today to find out how DMC can design, build, and program automated systems for testing and validation of a broad range of battery pack and battery management system (BMS) designs. You can view and download this document as a PDF.

The post Everything You Need To Know About EV Battery and BMS Testing in Validation and Production Scenarios appeared first on DMC, Inc..

Table of Contents

• Customer Benefits
• Flex Blocks and Flex Coordinators
• Ethos Behind the Flex Framework
• Standout Flex Blocks and Code Features
• DMC Module
• DMC Device
• Typical Application Module/Device Lifecycle

Customer Benefits

Open Solution: DMC can provide clients with license-free source code, allowing clients to extend or explore the code.

Extensible: DMC’s Flex Framework is based on a proven, scalable, LabVIEW Object-Oriented architecture.  This allows for DMC engineers or clients to add pieces/functionality to an application while keeping the overarching application architecture managed and maintained, enabling faster development.

Re-Usable CodeBase: Solutions start from a vetted architecture and drivers proven out over multiple projects, instead of re-creating integration logic.  Projects also get the benefit of improved supportability as DMC continues to advance and improve the Framework, which can benefit any project that uses the architecture. 

Modular Design: The Flex Framework consists of a collection of stand-alone software packages, which have the potential to be utilized outside of the Flex Framework or extended within the Framework. 

Flex Blocks and Flex Coordinators

DMC’s Flex Framework consists of two key elements:

• Flex Blocks
  • Component pieces that perform an action in an application. Some examples are:
    • Digital Multimeters
    • Power Supplies
    • Graphing Displays
    • DAQmx cards
    • XNET/CAN cards
    • HMIs
• Flex Coordinators
  • Constructs which integrate, manage, and build the Flex Blocks into a focused solution

Flex Coordinators, such as the Test Stand class, pull from the library of Flex Blocks to create a tailored solution for each client.  Flex Coordinators are the ‘brains’ behind the application and serve as the string that ties the Flex Blocks into a functioning software package.

Flex Blocks modularize one task, device, or feature set, and are designed to be agnostic of other Flex Blocks wherever possible.

Ethos Behind the Flex Framework

The Flex Framework provides a tested and proven starting point for projects eliminating the development time it would take to build up these capabilities from scratch. Furthermore, it establishes a modular design pattern which enables developers to adapt and expand the Flex Framework to client requirements.

Common Code

Common code, such as device drivers, do not need to be re-written for each new solution or project. Instead, DMC has developed this code once to be shared and improved in a single location so many of our clients and projects can benefit from future changes or feature additions.

Hardware Abstraction Layer

It’s common to have many different brands and types of COTS devices in a test system, but many of them do nearly the same thing. For this reason, interaction with individual devices (i.e. Digital Multimeters (DMMs), Power Supplies (PS)) has been abstracted in more general classes. Children of these LabVIEW abstract classes implement specific methods to add device-specific functionality and meaning to the parent’s method. For example, an abstract parent “_Power Supply” class provides a common interface for all Power Supplies, but the children of this class (Agilent HVPS, Lambda ZUP power supply, RMX power supply, etc.) implement the hardware-specific drivers and communication protocols through which the interface acts.

Multi-project interface coherence

Each test system may have unique characteristics, but it’s usually desirable to retain commonality in the underlying code modules, LabVIEW user interfaces/user experience (LabVIEW UI/UX), and system design. This enables users to have a consistent experience when moving from one test station to another (i.e. EOL Test Station, R&D Test Station). There are also programming benefits since ramp-up on a new project that leverages the Flex Framework is quicker and lowers overall development cost.

Code Modularity

The Flex Framework has code modules that are as independent as possible, allowing them to be re-used without dragging unwanted dependencies into a project. DMC Flex Blocks are agnostics of the existence of other Flex Blocks. Only the Flex Coordinator knows about each Flex Block included in the application. This software encapsulation and modularity keeps code more maintainable over time, which provides greater value to end-users of the Flex Framework.

Standout Flex Blocks and Code Features

DMC’s Flex Framework has many Flex Blocks and features which we have explained in separate case studies:

• Alarm Handling
  • Provides traceability for system faults and notifications
  • Allow for system recovery from faults or errors
  • Standalone toolkit
• User Access Levels
  • Easy to integrate toolset which keeps track of user permission levels
  • Simple to extend and tailor to customer’s user role definitions
• Data Logging/Reporting Capabilities
  • Flexible logging utility
  • Live feedback of user-configured, graded, testing parameters in LabVIEW
  • Standalone toolkit
• DMC Grid Viewer
  • Dynamic test interface configuration
  • Subpanels any LabVIEW VI and allows for drag-and-drop interface configuration
  • Standalone toolkit
• Tailored User Workflows
  • Application-specific interfaces and implementations to tailor the Flex Framework to exact customer needs
• Manual/Automatic Control Modes
  • LabVIEW Testing automation abstractions
  • Automated running of pre-configured testing routines
  • Manual testing support, for in-depth engineering diagnostics
• Configuration Management with Workspaces and DUT construct
  • Configuration Management
  • Single click switching of Device Under Test (DUT)-specific configurations
• Test Execution with the DMCquencer
  • LabVIEW Test Execution Engine
  • Test automation
• Built-In Diagnostics
  • I/O Checkout Routines
  • System self-diagnostic check
  • Diagnostic Logging
• Hardware Abstraction Layer
  • Test stand hardware hot-swap support
  • LabVIEW design pattern

DMC Module

DMC Flex Framework’s LabVIEW Object-Oriented architecture is based on a lightweight class named the DMC Module.  Most of the classes in the Flex Blocks group are grandchildren of the DMC Module class.  Modules are independent pieces of code responsible for a particular function.

DMC Modules introduce the concept of a ‘Module Command.’  These commands are used to capture a given Module’s API usage, keep track of the data modified by those API calls, and provide a level of traceability to an application.

Additionally, the Module class allows for the definition of daemons and/or interfaces which the Module may use to meter out tasks, maintain heartbeat communication with a device, or provide a user interface for an operator.

DMC Modules are typically software constructs which don’t have physical manifestations (i.e. database loggers, file writers, and data processing tools)

DMC Device

The DMC Device class inherits from the DMC Module class and is its most commonly used child.  DMC Devices add one additional piece of functionality: variable publishers.  Most classes in the Flex Blocks group are children of the DMC Device class.  Like Modules, Devices are meant to be independent pieces of code (i.e. they do not interact with or know about the existence of other DMC Devices).

Variable publishers are used in the Device Command architecture (which draws from the DMC Module Command architecture).  If a device API is called with the Device Command constructs, then the class is able to post ‘modified’ variables to a registered variable publisher.

Keeping track of modified variables allows for a single place in an application to monitor variables (an example of this could be a Current Value Table).  DMC uses this collection of device variable values to monitor the health of a test system, abort automated testing if a variable violates a safe operating range, and centralize reporting of system variables through the application’s lifecycle.

DMC Devices are usually classes which interact with physical hardware (i.e. digital multimeters, power supplies, relay modules, DAQmx hardware). 

Typical Application Module/Device Lifecycle

Many of the projects which utilize the DMC Flex Framework follow a common pattern:

1. Application is launched
2. User configures settings
3. The user chooses to run an automatic test or manually interact with the system (Manual Mode or Automatic Mode)
4. The testing Mode (Manual or Automatic) is active until the test finishes or the user clicks ‘Abort’
5. The system goes to an idle state
6. Repeat Steps 2-5 as needed
7. Application is closed

To accommodate this application lifecycle, a corresponding Module/Device lifecycle is managed by the Flex Coordinators by breaking the Modules/Devices into two groups:

• Eternal Modules/Devices
  • Active through the entire application lifecycle
  • Examples include interlock monitoring devices, database connection modules, etc.
• Session Modules/Devices
  • Active during the testing mode only. Constructed/initialized when the test begins and terminated/disposed of when the test mode completes
  • These are typically constructed on application start and parameters pulled from a System Parameters file, but then are disposed of and re-constructed when a test begins
    • This is done to capture any settings (and subsequent System Parameter file) modifications prior to starting a test

An example lifecycle of both Eternal and Session Modules/Devices are shown below.

National Instruments / LabVIEW Experience

DMC has been a National Instruments (NI) Alliance member for over 10 years with one of the largest teams of Certified LabVIEW developers in the country, including several National Instruments’ Certified LabVIEW Architects (highest level of certification available), and multiple NI Certified LabVIEW Developers.

DMC is proud to be recognized as a National Instruments Alliance Partner. Learn more about DMC’s National Instruments partnership and contact us today to find the Flex Framework solution that’s right for you.

The post DMC Flex Framework: A Flexible LabVIEW Toolset appeared first on DMC, Inc..

With more than just a few VIs, proper use of code management tools is essential. LabVIEW programming provides a variety of good options, but choosing which tools to use for various scenarios requires an understanding of both the broad intent of the tool as well as nuanced differences between them.

Project Libraries

LabVIEW project libraries are collections of VIs, type definitions, shared variables, palette files, and other files, including other project libraries. When you create and save a new project library, LabVIEW creates a project library file (.lvlib), which includes the properties of the project library and the references to files that the project library owns. A project library file does not contain the actual files it owns, unlike an LLB, which is a physical directory that contains VIs. Files that a project library owns still appear individually on disk in the directories where you saved them.

Classes

You create user-defined objects in LabVIEW by creating LabVIEW classes. LabVIEW classes define data associated with an object, as well as the methods that define the actions you can perform on the data. The benefits of encapsulation and inheritance allow you to create modular code that is easy to change without affecting code throughout the application.

In LabVIEW, the data of a class is private, which means only VIs that are members of the class can access the data. You define the data of the class in the private data control. When you create and save a LabVIEW class, LabVIEW creates a class library file (.lvclass) that defines a new data type. The class library file records the private data control and information about any member VIs you create, such as a list of the VIs and various properties of the VIs. The class library is similar to the project library (.lvlib). However, the class library defines a new data type.

The private data control is a unique class library file that defines a cluster of data for the new data type and is the data on the class wire. LabVIEW does not save the private data control on disk. Instead, LabVIEW saves it inside the class library file. Saving the private data control inside the class library file allows LabVIEW to ensure that you never use the wrong private data with the class definition.

Packed Project Libraries

LabVIEW packed project libraries are project libraries that package multiple files into a single file with a .lvlibp file extension. The top-level file of a packed library is a project library. By default, the packed library has the same name as the top-level project library.
All VIs in a PPL are pre-compiled, which means:

1. These VIs are only changed/updated when the PPL is built.
2. They are built specifically for one version of LV and one specific target.

When you open a packed library, you see only the exported LabVIEW VIs. Exported VIs are VIs in project libraries with a public access scope or VIs in LabVIEW classes with a public or protected access scope.

VI Package Manager

VI Package Manager (VIPM) is a package management tool that organizes and maintains packages within your LabVIEW environment. It’s a tool for obtaining and configuring libraries and development tools, but you can also subscribe to shared repositories created with VIPM. These various third-party development libraries and tools are supported for download via the LabVIEW Tools Network or the VI Package Network.

VIPM allows you to quickly access third-party networked code repositories and get them into your LabVIEW development environment quickly. With this, it also helps you build your own reuse tools into packages that can be installed in LabVIEW. VIPM has configuration management features that help you configure your LabVIEW development environment for your current project.

VI Package (.vip)

A package is a file that contains all the necessary components wrapped together, along with the actual tool that is to be installed. The package provides information related to its destination, compatible LabVIEW versions, etc. Package files are saved in the *.VIP format.

VI Package Build (.vipb)

These files are a close parallel to the LabVIEW application build spec.
Various aspects of the build are defined, including:

1. Package properties/metadata (Name, company, author…)
2. Source directory/files included
3. Output directory
4. Destinations for package deployment (vi.lib, user.lib, etc.)
5. Source file settings
6. Advanced:
   1. Install/versioning requirements
   2. Dependency management tools
   3. Licensing/activation tools

VI Package Configuration (.vipc)

This is a list of packages that is managed as a group and can be deployed for use with a specific LabVIEW version. This list can be saved to a file and later recalled and applied. Package configurations are saved as *.VIPC files, and you can create package configurations using the VI Package Configuration Editor window.

Learn more about DMC’s LabVIEW programming expertise.

The post Tools for Managing Your LabVIEW Source Code appeared first on DMC, Inc..

Thus, as part of DMC’s standard project process, there are many critical supporting services that DMC performs for our clients.

Here are five ways DMC ensures the success of projects: 

1. Design Reviews
2. Application Testing and Project Quality 
3. Build and Release Management
4. Project Communication
5. Project Management

This blog details each of these practices

Design Reviews

Design Reviews are standard practice for all DMC projects. Peers and senior engineers subject system designs and developed code to a constructive review. They serve as checkpoints and establish an active feedback cycle during project development.

Design Reviews:

• Improve quality
• Leverage experience of multiple team members
• Mitigate risk
• Allow early detection of system critical items 

Application Testing and Project Quality 

All custom application software requires testing. DMC integrates application testing throughout project development, from early-stage concept and simulation testing to onsite/field functional testing. 

Testing times naturally vary based on the use case and complexity of a system or application, but it is always reasonable to expect a significant amount of time be devoted to thoroughly exercising and verifying application functionality to ensure it satisfies system requirements. 

As part of DMC’s standard project process, at least one engineer is assigned to be the project quality lead, having responsibility for quality control measures throughout the project.

Build and Release Management

Standard software release processes involve the compilation and distribution of a binary (stand-alone) application, along with deployment to field systems (i.e., PCs, embedded controllers, or other targets).

Time spent on these activities varies with the scale of an application and its deployment scope. In all cases, the successful installation and configuration of application software on field systems is an important task during the end stages of a project. 

In addition to application builds that are released/deployed on field systems, DMC also typically provides full source code as a project deliverable.

Project Communication

DMC maintains open and active channels of communication with client personnel throughout our projects during all periods of ongoing engineering/development. We update clients on progress, schedule, and timing expectations, or identify any issues encountered. We also meet with key members of a client’s engineering and management teams to review technical information, hardware and software designs, project progress, budget status and schedule. 

Methods of communication:

• Status updates via email 
• Conference calls
• In-person meetings 

By regularly gathering appropriate project stakeholders, these meetings strive to promote effective communication, synchronization, and coordination between team members from both the client and DMC. They help ensure all development activities are progressing in line with the client’s expectations. 

Furthermore, these meetings provide an opportunity for DMC to obtain feedback and direction on the client’s preferred handling of various aspects of the project and to cooperate with client engineers on technical strategies and implementation approaches. The fundamental goal of these meetings is to enable the client and DMC to collaborate as a complete, cohesive team working together with a common purpose.

Additionally, DMC holds regular meetings amongst our internal engineering teams to ensure alignment and synchronization of technical strategies and deliverables.

Project Management

When DMC undertakes a particular scope of work on a project, we provide project management over that scope.

Project management includes:

• Coordination
• Top-level strategic direction
• Oversight
• Scheduling
• Tracking/reporting on team activities
• Monitoring progress, quality, schedule, and budgetary status

If desired, DMC also provides periodic project financial summaries (like the one shown below) for any Time and Expenses portions of the project.

Reports can be generated at significant project milestones/intervals to provide clear visibility into the budget as the project progresses. Data is based on invoiced costs and not-yet-invoiced pending costs (i.e. time spent by DMC engineers since the last invoice was issued) to provide an up to date snapshot of current budget status.

Conclusion

You can set yourself up for success before your project gets started by putting measures in place to prevent common and even uncommon barriers and problems from becoming a major breakdown in the project’s progress. If you have any questions about DMC’s project process, feel free to contact us. 

Icons made by Prosymbols, Vectors Market, DinosoftLabs, and Freepik from Flaticon are licensed by CC 3.0 BY.

The post 5 Ways DMC Engineers Ensure Project Success with Critical Support appeared first on DMC, Inc..

This article describes why developing a comprehensive Acceptance Test Plan (and then rigorously applying it) is important to overall project success.

Benefits of an Acceptance Test Plan

An Acceptance Test Plan provides many significant benefits to the project process.

Improves System Quality

Perhaps the most obvious benefit of an Acceptance Test Plan is that it provides a systematic, trackable, structured, and unified approach to performing system verification and validation.

Saves Calendar Time

Save time by parallelizing the work of fully defining test cases up front (as the Acceptance Test Plan is formulated), instead of doing this in-line (thus on critical project path) during actual commissioning activities. This minimizes total calendar time required for testing activities.

Reduces Engineering Time Spent on Testing

Writing a good Acceptance Test Plan takes time, but performing those tests takes even MORE time. Developing a complete Acceptance Test Plan in advance allows the full team to review and refine the plan prior to starting commissioning. This facilitates consensus agreement on what to test how it should be tested. This makes commissioning time more focused and productive.

The Plan Gets Utilized Twice for a Dual Benefit

The Acceptance Test Plan can be applied both during the upfront development level or “simulated” testing phases, and during final commissioning of the completed system. Thus, many of the benefits of an effective test plan get magnified. Although some aspects of the Acceptance Test plan won’t apply to the preliminary testing stage, there is still a significant ROI across the subsequent stages.

Guides and Supports System Development

Good test plans inherently flush out any ambiguities, gaps, or misunderstandings relating to system requirements. Applying these corrections sooner saves time and money.

Establishes Clearly Defined Milestones for Completion

Define successful completion of the project, or at least the current phase. A good Acceptance Test Plan avoids ambiguity or discrepancies on what it means for the system to be “working the way it needs to work.” Under the guidance of a good Acceptance Test Plan, all members of the team (both Client personnel and DMC) are striving towards a mutually understood goal.

Characteristics of a Good Acceptance Test Plan 

As a point of reference to everyone involved in the project, DMC suggests that a good Acceptance Test Plan should exhibit the following characteristics:

• Once it’s successfully executed, the Client is confident that the new system is properly doing its job, and that it will meet business needs.
• The Acceptance Test Plan should clearly define all test cases needed to accomplish the above goal. Each such case should:
  • Define the relevant input parameters and setup (both hardware and software) that need to be in place to start the test.
  • Define the process to execute that test case in clear, concrete, and actionable terms. This makes testing activities repeatable and self-documenting. Later, someone can look back and see a pass/fail result and exactly how it was created.
  • Define the expected results and/or pass-fail criteria for that test in clear, unambiguous, quantifiable terms. Tests should be broken down to a level where the answer to “Did it do what it was supposed to do” is a very clear YES or NO answer. 
    • Bad: The Configuration GUI screen operates as expected.
    • Good: When the “Save As” button is pressed, the operator is prompted with a “Browse” dialog, allowing them to select a file path and file name.  
    • Good: When “OK” is pressed on this Browse dialog, the program saves the parameter file in an INI format in the specified file path location with the specified file name. The parameter file shall contain all previously entered parameter values.

Return on Upfront Time Investment 

The following questions commonly arise when considering Acceptance Test Plan development:

Is it worth it to spend this time to define how the system needs to be tested, and exactly how each test will be conducted?  

Aren’t we smart enough to figure this out as we go along?

When developing complex, customized, and mission-critical systems, omitting rigorous system testing from the project process is NOT an option. Doing so may detract from the quality of the final system and risk unacceptable failures and issues.

It is true that defining the full process for each test case is no small task and will take some time. It’s critical to keep in mind that, to perform any commissioning tests, the work to define tests must still be completed at some point. 

We have two options for when to figure out these details:

• During acceptance testing – In this case, all work happens in-line with actual commissioning/testing activities. It is on the project critical path and adds time to overall project schedule.
• Before acceptance testing/commissioning – Include this information in a pre-defined Acceptance Test Plan. In this case, all time happens in PARALLEL to other critical path development activities, and IN ADVANCE OF actual commissioning activities. This effort is parallelized, off the critical path, and has limited impact on overall project schedule.

Another time-saving benefit is that, once documented in an Acceptance Test Plan, tests can be reliably repeated. If something fails once (which is going to happen many times in a complex system), having a good Acceptance Test Plan means that, after making corrective modifications to the system, any person will be able to conduct the same test in the same way it was originally done.  

Moreover, this can be done without needing to re-formulate the steps and without requiring that the exact same people conduct the test. An Acceptance Test Plan adds structure, documentation, and repeatability to the test process.

Who Should Write the Acceptance Test Plan? 

The generation of the Acceptance Test Plan should be a collaborative effort among all team members. Certain team members know specific aspects of the system better than others, and all members of the team are invested and share responsibility in making sure the system works properly and meets Client needs.

DMC suggests that the Client team is best suited to have primary responsibility for creating the Acceptance Test Plan.

Why is this the case?

The Acceptance Test Plan will be the primary way for the Client to exercise “quality assurance” over the new system and make sure it does the job it needs to do. When push comes to shove, “the job it needs to do” is a matter of the Client’s business needs. Thus, the definition of how to check if the system is doing its job (i.e., the Acceptance Test Plan) is most meaningful if it comes from the relevant stakeholders and end users on the Client’s team.

Additionally, having client stakeholders develop test cases creates a system of “checks and balances.” A supporting purpose of an Acceptance Test Plan is to verify that the developers correctly interpreted each requirement. For example, if DMC writes a test case about a particular requirement, it’s inherently based our interpretation of the requirement, which will naturally align with how we implemented that requirement. The system is likely to pass that test case, whether our requirement interpretation is accurate.

Therefore, it’s generally not best practice for developers to create the final test cases for their code. Test cases are often driven by those who are the “end users” of the given system. Having Client stakeholders develop test cases creates a system of “checks and balances” and enables the Client to act in an oversight capacity for system quality assurance.

Requirements Vs. Test Cases

A common view on test strategies is that testing should consist of going through the original requirements document and checking that each requirement is satisfied. This makes sense because a good Acceptance Test Plan should essentially be a set of test cases that provide 100% coverage of the system requirements. However, the requirements document is not an Acceptance Test Plan. There is a fundamental difference between a requirement (a statement of what a system shall be capable of) and a test case (a statement of conditions to establish, steps to follow, and criteria to evaluate to determine if a system is meeting a requirement). Yet there is a close correlation between requirements and test cases.

DMC recommends that one should reference the system requirements documentation while drafting the Acceptance Test Plan. We should be translating and expanding each requirement into a test case (or multiple test cases) that effectively checks whether the system is meeting that requirement. If we do this for each system requirement, we end up with a good Acceptance Test Plan that has 100% coverage of the requirements. 

The post Deciding If Your Project Needs an Acceptance Test Plan appeared first on DMC, Inc..

For those who are true engineers/developers at heart, the ability to bring something new and useful into the world provides its own reward and sense of fulfilment that can make all the effort involved seem worthwhile.

But no matter how enjoyable DMC’s projects are to work on, the fundamental fact remains that DMC must charge for these projects to support company operations and to provide for employee growth and long term sustainability for our clients and vendors.

So how does DMC operate when it comes to defining budgets, managing the scope of work, and billing for projects?

DMC projects customarily follow one of two engagement models: Time & Expenses or Fixed Bid. Some multi-phase projects may involve a combination of the two approaches.

There are many factors to consider when deciding which option is best suited for a given project. The table below compares the two engagement models side by side to show how they might affect important aspects of the DMC project process. Every project is different, but these are some of the things we take into consideration when helping customers choose an approach that’s best for their needs.

The post DMC Engagement Models: Time & Expenses vs. Fixed Bid appeared first on DMC, Inc..