This article walks through the fundamentals of FAT, how it differs from other testing phases, and how to prepare your system and your customer for a smooth buy-off.

Background

Before we dive into the topic of Factory Acceptance Testing, I want to outline an example of the Project Process DMC follows. After thousands of projects, DMC has found that a phased approach is the best way to make a system production-ready.

• Requirements & Specifications – DMC works collaboratively with the client to determine system requirements. This phase often culminates in a “System Functional Review.”
• Preliminary Design – DMC defines a Preliminary Design as a ~20% complete design, where the high-level architecture has been mapped out and identified risks have been evaluated to the point where a plan is in place. This phase often culminates in a “Preliminary Design Review.”
• Comprehensive Design – DMC defines a Comprehensive Design as an ~80% complete design, with the remaining tasks to be finalized during the Development & Fabrication phases. (i.e., what nuts and bolts will be used to mount the hardware). This phase often culminates in a “Critical Design Review.”
• Development – The software development portion of the implementation phase, where any custom software is created and tested.
• Fabrication – The hardware build portion of the implementation phase, where any hardware is assembled into a complete system.
• Factory Acceptance Testing – The point in the project process where DMC validates the system prior to shipping it to the client site.
• Site Acceptance Testing – The final validation testing performed after the system arrives at the client site.
• Training & Support – After delivery and acceptance, DMC can provide training on using or extending the system, as well as support for troubleshooting and future improvements.

Learn more about DMC’s Project Management that makes this flow happen.

Project Specific Customizations

At DMC, we understand that not all projects are the same, so the Project Phases are customized on an individual project level.

• If a customer already has a well-defined Requirement & Specification document, we can jump straight into the Design phases.
• For small projects, we might combine “Requirement & Specification, Preliminary Design, and Comprehensive Design” into a single “Design” phase.
• For software-only projects, we remove the Fabrication phase and may combine “Factory Acceptance Testing and Site Acceptance Testing” into a single “Testing” phase.

Now that we have a better understanding of DMC’s typical project process, let’s talk about how we can prepare for a successful Factory Acceptance Testing phase.

FAT vs. SAT vs. ATP: What’s the Difference?

Before we dive into any details, let’s define terms that will be used in this blog.

Factory Acceptance Testing (FAT)

FAT is testing at the fabrication location to verify that the system meets the agreed-upon requirements before shipment. FAT focuses on testing that can be performed without the systems or hardware only available at the customer’s facility.

Site Acceptance Testing (SAT)

SAT is a test conducted after the system has been installed at the customer’s facility and is the first opportunity to test with systems or hardware only available at the site. SAT will often repeat tests performed during FAT to ensure the system wasn’t damaged during transport.

Acceptance Test Plan (ATP)

The ATP is the test plan used to execute FAT or SAT. It defines what is tested, how it is tested, and what constitutes a pass or fail. A well-written ATP is essential for efficient execution and clear customer sign-off.

What Does a Successful FAT Look Like?

FAT is successful when all parties are in agreement that the system meets its requirements and is ready for shipment to its final location.

How Do We Ensure FAT Is Successful?

Preparation is critical to ensuring that FAT is an efficient and productive use of time. We will dive a little deeper into how we can maximize testing prior to FAT, define participation and roles during FAT, and how to develop the ATP.

What Testing Should Occur Before FAT?

FAT should not be the first time testing occurs during the project process. Systems and code should be tested as they are developed. Testing strategy is a huge topic and will not be discussed further in this blog.

Who Participates During FAT?

At DMC, customer involvement during the FAT process is highly encouraged. At the end of the day, the customer will own and operate the system, so DMC strives to include the customer in as many aspects of our project process as possible. Some benefits of customer involvement during FAT are:

• A chance to make tweaks to the system without major cost or schedule impacts to the project.
• An opportunity to receive hands-on training with the team that developed the system.
• Provides an opportunity to identify gaps or misunderstandings in requirements.

Regardless of whether or not the customer attends FAT, they should be involved in developing the ATP. Ideally, either DMC or the client would write the acceptance test plan, while the other reviews and approves.

Typically, the customer should be responsible for writing the acceptance test plan to ensure complete test coverage and feel comfortable accepting the system at the end of the day. However, DMC engineers are experts and will often develop the ATP.

How Do You Develop an ATP?

Each item in an ATP should be clear, repeatable, and objective. In order to achieve this goal, each test should have the following core elements at a minimum:

• Test Procedure: Step-by-step instructions
• Acceptance Criteria: Objective pass/fail conditions
• Observed Results: What actually occurred
• Result Files: Logs, screenshots, or data files as evidence

Depending on your specific requirements, you can also consider tracking the Test Type, Test Operator, Test Date, and the approval status of Individual Results. If you’re looking for more information on why you might need an ATP, check out this blog.

Does the Order of ATP Execution Matter?

The order of individual ATP items is crucial for reducing the amount of time spent troubleshooting and debugging the system. The highest system-level impact should come first, followed by more narrowly scoped items. This narrows down potential causes of issues, reducing the overall time spent troubleshooting and debugging the system.

As you test systems and subsystems, start with the simplest components and add more complex capabilities sequentially.

A high-level concept for ATP Execution Order is as follows:

Conclusion

Factory Acceptance Testing is more than a checkbox. By involving the customer early, planning FAT thoughtfully, and executing against a clear, well-structured ATP, teams can streamline buy-off, minimize rework, and set the project up for long-term success.

The post Factory Acceptance Testing 101: Preparing for Customer Buy-Off appeared first on DMC, Inc..

Our adventure kicked off at Urban Family Brewing, a welcoming spot with a relaxed atmosphere. Its taps are constantly rotating, so there is always something new to sample. While Urban Family Brewing is known for sours, our favorite pour of the day was the Raccoon-Level Dexterity, a New England IPA. 

Next, we made our way to Wheelie Pop Brewing, a newer addition to Ballard’s brewery scene. Wheelie Pop favors crisp, clean beers like lager and pilsner. However, its Green Sector IPA was the crowd favorite from our team.  

We strolled through the neighborhood until we reached Reuben’s Brews. The family business has been brewing in Ballard since 2015. It offers a wide range of styles and has won many awards for its delicious brews. On this visit, we opted for the summery sour ale Fresh! Watermelon Lime. 

Our last stop was Stoup Brewing. Its founders have a background in chemistry and biology, so its beers balance science and art. You’ll find many lagers and IPAs on tap at Stoup Brewing, but we voted for the Wheat the Rich raspberry wheat. 

The Ballard Brewhaha was a fun way to step away from the office and connect as a team. From exploring the historic Ballard neighborhood to sampling its craft breweries, it was great to spend time together outside of the workday. What Seattle neighborhood should we check out next? 

The post Exploring Ballard for DMC Seattle’s 4th Annual Ballard Brewhaha appeared first on DMC, Inc..

What is CMMC? 

The Cybersecurity Maturity Model Certification (CMMC) is a DoD-developed framework designed to assess and enhance the cybersecurity posture of organizations that handle sensitive government information. Unlike self-attestation models of the past, CMMC introduces standardized practices, processes, and third-party assessments to ensure consistent protection across all contractors and subcontractors.

Understanding CMMC Level 2

CMMC Level 2 is designed for organizations that handle Controlled Unclassified Information (CUI). It requires full implementation of the 110 security controls defined in NIST SP 800-171, covering areas such as: 

• Access control 
• Incident response 
• Risk management 
• System and communications protection 
• Configuration management 
• Audit and accountability 

For more information, visit the Department of Defense website. 

DMC’s Commitment to Cybersecurity

DMC has long prioritized security, quality, and operational excellence across our engineering and technology services. Our ongoing efforts toward CMMC Level 2 compliance build on that foundation, strengthening internal controls, policies, and processes to align with DoD expectations. 

By working toward CMMC Level 2 by year’s end, DMC is positioning itself to continue supporting customers in regulated industries while reinforcing our commitment to protecting the data entrusted to us. 

The post DMC’s Path to Cybersecurity Maturity Model Certification (CMMC) Level 2 Compliance  appeared first on DMC, Inc..

A Mind-Bending Experience 

The museum is located a short walk away from DMC’s Seattle office, so we planned to visit it on a weeknight after work. We kicked off the evening by ordering dinner at the office to fuel up before our adventure. Then, a group of eight of us, including some of our guests, set out to explore the museum. 

Our eyes couldn’t believe what we saw after arriving at the Museum of Illusions. There was a variety of optical illusions to interact with and pose for fun photos.  Some rooms made you feel like you were shrinking or growing while others played tricks on your eyes. Our team had a blast together trying to figure out how the illusions worked and snapping silly photos of each other. 

One of the highlights of the outing was a tunnel at the end of the museum. It had a spinning circular wall that created a dizzying effect, making it tough to maintain your balance. People struggled to walk through it, with some of us nearly stumbling over as we tried to keep our footing through our laughter. 

This Magic Moment 

After regaining our balance, having our minds blown, and taking way too many pictures, we all made our way home. Our magical evening at the Museum of Illusions was the perfect way to embody DMC’s core value of “Have Fun.” It was great to enjoy the museum’s whimsy as a team and literally see things from a different perspective. 

The post A Magical Evening at the Museum of Illusions in Seattle appeared first on DMC, Inc..

How to "Enable/Disable" Custom Device Functionality

1. Updating the Custom Device Main Page GUIDs
2. Adding the “EnableDisable Main Page.vi” to the System Explorer library.
3. Updating the Custom Device XML Run Time Menu (RTM) to allow the user to enable and disable the Custom Device.

Updating Custom Device Main Page GUID

By default, the Template Custom Device generates a Main Page with a single GUID. To fully enable this functionality, two GUIDs are actually needed for the Main Page.

Within the “Custom Device Shared.lvlib:Constants.vi”:
1.    Rename the “Custom Device” GUID to “Custom Device Enabled”.

a.    You may have to update the rest of the code that references this GUID by the original name.

2.    Create a new constant named “Custom Device Disabled."

3.    Generate a new GUID for the “Custom Device Disabled” using the method of your choice. 

a.    I typically use an online GUID generator.

4.    Save the new GUID value as the default value for the new constant.

Before:

After:

Updating the System Explorer Library

LabVIEW VIs can be called from the System Definition Editor. This is done by adding action VIs which can contain all sorts of functionality such as adding new channel groups. These action VIs are then linked to an RTM item for the Custom Device. In this case we are going to create a VI to enable or disable the custom device. 

Create a new VI called “EnableDisable Main Page.vi” in the Actions directory of the Custom Device System Explorer. This VI is responsible for switching between the Enabled and Disabled GUID for the selected Custom Device.

Add the following logic:
1.    Custom Device API.lvlib:NI VeriStand – Get Item GUID.vi
2.    Custom Device API.lvlib:NI VeriStand – Set Item GUID.vi
3.    Custom Device API.lvlib:NI VeriStand – Update Custom Device Flag.vi
4.    Simple Error Handler.vi
NOTE: Ensure that the Item Reference in is named “Node Ptr."

Updating Custom Device XML

Each Custom Device has an associated Run Time Menu (RTM). In this case, the Export Configuration was included by default. The following instructions will show how to create a new RTM item.

Updating Main Page RTM

Each RTM “Menu Item” has the following important properties:
1.    GUID: This must be a unique GUID associated with this RTM Menu Item.
2.    Type: Action in this case means that a VI will be called when this RTM Menu Item is selected.
3.    Name: The text that appears for this RTM Menu Item.
4.    Item2Launch: Information to select which VI to launch.

a.    Type: “To Common Doc Dir” refers to the Public Documents folder where Custom Device code is stored (“C:\Users\Public\Documents\National Instruments\NI VeriStand 2020”). 
b.    Path: The path to the desired VI from the common directory specified in the Type property.

An example for Export Configuration is shown below:

We now need to add a new RTM Menu Item for the “EnableDisable Main Page.vi” that we just created.
1.    Add new <MenuItem>
2.    Add new <GUID>

a.    For this menu item we will need to create a new GUID since there is nothing associated with it in our system explorer constants VI – the shared GUIDS are only for the top level pages

3.    Add new <Type>
4.    Add new <Name>
5.    Add new <Item2Launch>

Duplicate Custom Device Main Page Definition

As a part of setting up the Enable/Disable functionality, there must be two separate page definitions in the Custom Device XML to match the different GUIDs that were created earlier. The first step is to create a copy of the Main Page definition, then make the following changes:

1. Update Page GUID to match “Custom Device Disable”.
2. Update Glyph. (C:\ProgramData\National Instruments\NI VeriStand 2020\System Explorer\Glyphs)
3. Change the action name from “Disable” to “Enable”.

NOTE: You may want to ensure any other RTM changes for the Custom Device are implemented first. After setting up this functionality, all other changes will now need to be made in both page definitions.

After the Custom Device System Explorer has been rebuilt, the RTM should  have the ability to enable and disable individual instances of the custom device.

Check out these related blog posts:
How to Configure VeriStand Custom Device Upgrades By Version
How to Install the “NI VeriStand Custom Device Wizard”

Learn more about DMC's partnership with National Instruments.

The post How to Configure EnableDisable Custom Device Functionality in NI VeriStand appeared first on DMC, Inc..

How to Add Logic for Upgrading CD Versions

Implementing a basic version of this functionality will require creating two VIs and updating the Custom Device XML.

1. ActionVIOnLoad.vi

2. Mutate Version.vi

a. You can keep adding more Mutate VIs as the Custom Device continues to evolve.

3.    Update Custom Device XML

Implement the “ActionVIOnLoad.VI”

The ActionVIOnLoad executes when NI VeriStand loads a custom device item into memory. Therefore, we can use this VI to check if a new version of a Custom Device has been created. If so, we can implement whatever code is required to update the old version to a new version. An example of a change would be adding or deleting channels, but can really be anything you can fit into your VI.

The first step is to create an instance of the “ActionVIOnLoad.vi” in the Custom Device System Explorer

1. Custom Device API.lvlib:NI VeriStand – Get Custom Device Version.vi

a. Make sure the Custom Device XML version is updated when you build new versions of the Custom Device. 

2. Mutate VERSION.vi (See next section).

a. You will typically write a new Mutate VI each time you release a new version of the Custom Device.

3. Custom Device API.lvlib:NI VeriStand – Set Custom Device Version.vi

Implement “Mutate Version.VI”

This VI is responsible for making the updates from one version to another. This VI should also return the new version of the Custom Device.

Update the Custom Device XML

The Custom Device XML file must be updated to know that the ActionVIOnCompile.vi has been implemented.

1.Add the <ActionVIOnLoad> tag to the Main Page definition.
NOTE: Remember to add this code to both Enabled/Disabled page definitions if that functionality is enabled. 

[Add link to ENABLE/DISABLE BLOG POST HERE]

CAUTION: The <ActionVIOnLoad> must be added before the <ActionVIOnCompile>.

Before:

After:

Check out these related blog posts:
How to Configure EnableDisable Custom Device Functionality in NI VeriStand
How to Install the “NI VeriStand Custom Device Wizard”

Learn more about DMC's partnership with National Instruments. 

The post How to Configure VeriStand Custom Device Upgrades By Version appeared first on DMC, Inc..

Dependencies

NOTE: These instructions assume LabVIEW 2020 SP1 and NI VeriStand 2020 R4, but should be similar for other versions.

• NI LabVIEW 2020 SP1
• NI VeriStand 2020 R4
  • LabVIEW Real-Time 20.0
  • CompactRIO Driver 20.5
  • For additional dependencies, see VeriStand 2020 R4 Readme

Installation Instructions

1. Install “NI VeriStand Custom Device Development Tools.”

a. Ensure all the VIP dependencies are installed as well. 

2. Install “NI VeriStand Custom Device Wizard."

Once these packages are installed, the “CONSOLIDATED NI VeriStand Custom Device” template project should now be available when creating a new project.

Check out these related blog posts:
How to Configure EnableDisable Custom Device Functionality in NI VeriStand
How to Configure VeriStand Custom Device Upgrades By Version

Learn more about DMC's partnership with National Instruments. 

The post How to Install the “NI VeriStand Custom Device Wizard” appeared first on DMC, Inc..