CASE STUDY

Test Framework

Mirka Ltd

Test Framwork Mirka LTD

Test Framework for Mirka Ltd

Mirka Ltd is a world leader in surface finishing technology and offers a broad range ofgroundbreaking sanding solutions for the surface finishing and precision industry. The Mirka motto, ‘Dedicated to the Finish’, states the company’s high standards for all to see.The growing Mirka Power Tools department develops and manufactures advanced sanding and polishing machines, and continually focuses on innovative product and process development. Remaining in the technical forefront, and at the same time maintaining the company’s uncompromising quality requires an equally high paced development of test capabilities and coverage.

mirka test framework
Developing test rigs from scratch for each new product, and manually controlling them would make the cost of test increase at the same pace as the increase in functionality. Such a proliferation of test rigs would also become hard to maintain and create strong dependencies on specific individuals. In discussion with Novator Solutions, implementation of a standardized test framework would address all these challenges. Basing all of Mirka’s test rigs on a common flexible architecture makes it possible to create a single learning path for new employees to acquire the knowledge needed to maintain the rigs, as well as create new ones. It would also allow for faster development of test rigs, continuous improvement of the architecture, and an ever-increasing automation grade.

Project Overview

Training

The project started with a request for LabVIEW training. An engineer from Novator Solutions held a custom course for the test and verification team at Mirka. During the training, the challenges and costs associated with throughly testing a rapidly evolving product portfolio – and the concept of test frameworks as a way to meet those challenges – was discussed.

Workshop

A subsequent workshop was scheduled to discuss the general benefits the approach would give Mirka, and identify their specific requirements on such a framework. General requirements are modularity, flexibility and architected according to best practices, as well as specific instrumentation, sequencing and reporting needs were listed.

Implementation

The implementation of the framework and the first rig based on it was done by Novator Solutions engineers because of our experience in developing strong architectures. Mirka simultaneously trained personnel that could act as framework architects and test developers repsectively

Challenge
 

  • Test capability can become bottleneck in development
  • Test stations can have bugs
  • New product features forces development of new test rigs
  • Cost of test increase linearly with test coverage
  • Support of old rigs is difficult and expensive

Solution

  • Flexible architecture possible to apply on different products for fast rig development
  • Modular architecture allows reuse and thus continous improvements to each module
  • The flexibility and modularity allows expansion an repurposing of existing rigs
  •  Automation capabilities built in from the start, and continously refined, to allow higher test coverage without increasing cost.
  • Common architecture makes it possible to teach new employees how to support all rigs at once

Characteristics

A framework can be defined as a reusable codebase of high quality that can be scaled up or down without limiting its usability, and seamlessly extended with new functionality.

 

Requirements

  • Following high-level requirements for the test framework were identified: It should be modular – so that individual components can be reused in different configurations
  • It should be flexible – so that optimal hardware can be selected and test sequences can be created or adapted without changes to the overall architecture
  • It should produce user friendly rigs, including user interfaces, data storage and stability – so that rigs created become helpful tools to product specialists that can use them effortlessly, and if needed request new features from a test system architect.
  • It should be well architected according to best practices – so that new architects can be trained according to standardized learning paths, and that maintenance and development of the framework does not become dependent on
    specific individuals.

This singled out LabVIEW OOP as the ideal software tool because of the inherent object-oriented modularity, broad hardware integration, UI and data storage possibility, and existence of efficient classroom and online training.

It was decided that the framework should be treated as a product, not a tool. This means it will have a responsible owner, and a living backlog and bug reporting. This also makes it possible for Mirka to assign and train people for different roles in the test value chain.

 

 

 

 

 

Testsystem Mirka

 

Examples of components of a test framework:

Architectures
Documentation

        • Example code
        • Training material
        • Development guidelines

    Communicaiton layer

        • Inter-process communication
        • Network communication
        • Internet communicaton
        • Database communication

Well packaged software, such as libraries or object-oriented classes, to solve reoccurring tasks

        • Hardware drivers
        • Abstraction layers (HAL, MAL)
        • Report generation
        • Test sequencing
        • Monitoring
        • Data logging
        • Storage of metadata
        • Database integration
        • User interface
Features

A test rig consists of a LabVIEW OOP class inheriting from an overarching rig class. This rig class launches and manages communication interfaces, hardware layer, I/O-channels, logging, centralized error handling and other functionality needed.

 

I/O and sequencing are separated in a client-server model. This allows access to the measurements from different devices, also parallel devices. There is also the choice to deploy to either Windows or real time targets. It also enables usage of either a LabVIEW-based sequence engine and data visualization user interface for development tests, or TestStand for enterprise integration for production tests.

 

Hardware is integrated through a hardware abstraction layer. Modular NI hardware is the de facto standard for general measurements. This allows for cost efficient way of avoiding downtime as spares can be kept that can be used on multiple systems. Specialized instrumentation can be integrated seamlessly when needed. Sensors built into the Mirka electric sanders are also integrated through the HAL and natively used as instrumentation in the framework.

Other features that new rigs automatically benefit from through reuse and simplified setup are:

  • Centralized error handling API to allow and enforce consistent error handling.
  • User login for increased traceability.
  • “Report abstraction layer” for quick customization of reports to fit different products, but also the possibility to easily reconfigure existing rigs if the reporting template or file format are changed.
The process for creating new rigs is:

  • Reusing existing hardware drivers, or implementing new ones by inheriting from the HAL-class.
  • Reusing or developing new test steps, including control, measurements and calculations, and adding the steps to new or existing test sequences.
  • Configuring what data should be recorded and to where (report, files on server, database), no programming needed as long as report format has not changed.

In that way, Mirka leverages all work that has been on previous rigs today, and can continue to leverage todays work in the future.

Novator Solutions’ Development Process 

Novator Solutions uses the Scrum process framework for managing our development work. Scrum is a lightweight, iterative and incremental framework for managing complex work. The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

Novator Solutions’ Pricing Models

Novator Solutions offers two types of pricing models for turn-key systems, Fixed Price or Time & Materials. Development is always done using the agile programming framework Scrum.

Fixed price

In a fixed-price-project the deliverables and how to evaluate them are decided before the project starts. If needed Novator Solutions can perform a pre-study to help the customer identify the requirements.

Once we have the requirements, we provide a quotation with an all-inclusive price for a system that fulfills them, including factory and site acceptance tests to be performed to verify the functionality upon delivery. A product owner is appointed by Novator Solutions and we develop the system fulfilling the already agreed upon requirements.

 

Pros

  • No financial risk – customer knows from day one what they will pay

 

Cons

  • Limited possibility to reprioritize deliverables after order – deliverables must be thoroughly validated before project start.
  • Limited possibility of beta-testing or pre-releases. We work according to requirements document and
    test programs until full functionality can be delivered.
  • Commitment to pay full system delivery even if certain functionality is reprioritized.
Time & Materials

In a Time & Materials project, a scope for the project is set. A list of deliverables and preferably how to evaluate them are often decided on, and Novator Solutions give an estimate on the time we think it will take to implement the system.

A product owner is appointed by the customer, and a project manager by Novator Solutions. They stay in close contact throughout the project and meet up with regular intervals during which the deliverables list can be reprioritized, amended or deducted to achieve the best possible system with the least amount of investment.

 

Pros

  • Validation work of deliverables can be less thorough, which saves time.
  • Customer can test beta-versions of system and change deliverables to optimize it throughout the project.
  • Project can be closed as soon as the desired functionality level has been achieved. Or a first versions can be deployed while we continue to work on upgrades.

 

Cons

  • Customer has to take the financial risk of a decided upon termination period.

Regardless of delivery model chosen, we are always committed to the long term success of the systems we deliver. We offer service agreements to guarantee uptime and continuous upgrades, and to mitigate obsolescence of components.

Download the complete case studie here.

CONTACT

 

Please feel free to contact Jonas Mäki for more information.

Tel: +46 – 76 610 13 99
eMail: jonas.maki@novatorsolutions.se

 

We are looking forward to talking to you!