Configuration Engineering for Invitro-Diagnostic (IVD) Product Development

Editor's Notes

• #2: Dear INCOSE colleagues, let me briefly introduce myself. My name is Arnold Rudorfer and I am going to talk about Configuration Engineering for IVD Product Development. My company is Siemens healthcare Laboratory Diagnostics. There, I am responsible for CE, deployment of a new practice and technology moving from single product towards a journey of platform-based product development. I am with Siemens since 2000 in various roles and countries. [next slide]
• #4: One of my favorite activities is to be engaged at conferences sharing experiences obtained in product development and how they might be relevant for others in the field. So, let’s go over the content I want to address: First, I am going to go over the Goals of this talk and what Laboratory Diagnostics does for a living Secondly, within the IVD industry/ medical devices, I will discuss the underlying challenges of the industry and introduce configuration engineering as a workflow. With the understanding of the Engineering workflow, I am going to share 4 specific challenges, the approach to solve and engineering practice has been employed. To make it as concrete as possible, I am going to share quantitative data when possible. In a summary, key takeaways will help you leverage experiences and learnings I have made over the course of endeavor to setup configuration engineering. [next slide]
• #5: When we look at the goals if this presentation, I want to talk about how we are employing configuration management practices in platform product development as well as show what technologies and tools are used to desired outcomes. If you have questions during the presentations, please feel free to interrupt me. I do prefer to answer questions as they come up. [next slide]
• #6: If you look at our business LD is all about medical tests providing equipment's and assays to enable medical decision making. About 70% of decisions made by a physicians are triggered by medical test results. LD has a wide portfolio of tests and products from hematology to laboratory automation with a the largest installed base of analytical automation. [next slide]
• #7: Siemens Healthcare covers 2 large domains in MEDTECH, Diagnostic Imaging and Laboratory Diagnostic. Both domains need to cover a very different concerns of the customer. Diagnostic Imaging is enabled by advanced technology where the purchase price for an instrument is not necessarily the deciding factor though lowering reimbursement rates. In the laboratory diagnostic industry, price for equipment is very essential, so cost effectiveness is a key competitive advantage, it follows a printer business model. The revenue model is assay driven including a fee-based service. Whatever helps to drive the cost down needs to be considered. Linked to cost effectiveness is largely product variety – the more products you need to support with a high variety and little commonality the less competitive you are. A very well known truth is also that the faster you are on the market, you are likely to harvest most of the revenue for your product. Technologies introduced over the lifecycle of development projects, the higher the likelihood is to experience a growth in complexity. Over the past years, more and more companies have tried to move towards platform based product development supported by ALM and PLM tools. Platform-based development requires the not only a clearly defined reuse strategy, however in order to manage design assets in a reuse strategy, Configuration Engineering (or also called Configuration Management for Platforms) is a key discipline to be able to achieve expected gains over the lifecycle of projects. This is the major focus of this talk today. [next slide]
• #8: I think looking at an example of a product we have “a chemistry analyzer” provides you with some context on the product development projects I am engaged in and also to give you an idea about the complexity. [next slide]
• #9: So let me now introduce the notion of Configuration Management. “A disciplined, efficient workflow for evolving a product including its data and associated procedural information from cradle to grave with increasing precision and maturity”. Configuration Management by itself is all about managing changes mini, small and large in a controlled predictable manner along the lifecycle of a project. We are talking about changes in the area of hardware, software and firmware. The focus of the practices discussed here really refer to hardware and firmware changes, e.g. the design changes on a sub-system replacing a component with better performance characteristics. CM practices also need to be compliant with requirements of the FDA, an analyzer is a medical class II device. [next steps]
• #10: Once we move from single product development CM practices dealing with platforms, it is all about variety in many different aspects. There are 2 distinct categories of variety. One if external variety which is focusing to address different market segments, e.g. from low test volumes to very high test volumes (from 250K to 15 M tests per year) or the different types of tests from immunoassay, hybrid or clinical chemistry tests. From an entity perspective of analyzers, this translates into multiple analyzers put together to produce the desired test throughput. On the other hand, we are talking about internal variety which is all about maximizing commonality of product components and sub-systems (essentially implementing reuse). What is the relationship of Configuration Management in a platform based development setting? In order to enable platform-based configuration management, there is a need to amend configuration management with variant management. We call this new evolving discipline Configuration Engineering which is Variant Management (what) + Configuration Management (how). Based on best practices, we have come up with an end to end workflow for configuration engineering. [next slide]
• #11: Here is the big picture that we have established – a 12 step workflow which addresses the entire chain of CE activities from cradle to grave of an instrument development project. It is divided up into a CE frontend (1 to 7) and a CE backend (8 to 12) side parts. The CE backend side is mainly to address design changes from a development phase to the GA of a product. [next slide]
• #12: Here, we are diving into the next level of detail for Configuration Engineering. I will use the larger graphs to explain the frontend CE workflow consists of. [next slide]
• #13: Explain CE frontend workflow step by step. [next slide]
• #14: Explain CE frontend workflow step by step. [next slide]
• #15: Now, that you have a high level overview of the CE workflow, here are some of the aspects, I would like to focus on when talking about. They are: Managing product variants: How do I structure, assess and control product variability? Structure an efficient and reliable change management workflow: What is the best approach for executing change management? Managing changes across engineering disciplines: What do you do to manage and control product data across development projects? Coordinating design changes across Engineering and Manufacturing: How do I consistently synchronize Engineering and Manufacturing to become faster and less costly? [Next slide]
• #16: Here is just a brief look at where I personally found those questions to be highly relevant. [next slide]
• #17: A brief glance on how I am planning to address the content … [next slide]
• #18: [hide slide]
• #19: The possible highest leverage and possible positive impact for Configuration Engineering is clearly understanding the commonality and variability. At the end of the day, the clear understanding of commonality and variability enables the engineering group to provide a precise scope for project and program management. We are employing traditional feature modeling (a la FODA) to come up with the set of variation points in an instrument product model. Frontend CE is all about managing variation points in a feature model and the corresponding configuration rules in a configuration model to define product variants that the market desires. The feature model and the configuration model are then linked up with architectural building blocks and it is possible to define a generic bill of material. [next slide]
• #20: A challenge is all about establishing an efficient, reliable change management workflow that is also compliant with rules and regulations. In a mechatronics development project, the handling of changes. e.g. upgrade of firmware for a vision system or a control for a transport mechanism requires not only a thorough understanding of the change content itself, however, also its processing and the different types of changes with the required set of documentation. On the schema you see depicted is the gBOM, eBOM and mBOM. The different colors indicate revisions on components – change in a specification with annotations to adhere to design standards from gBOM to eBOM, and from eBOM to mBOM a revision of a design to make it less costly. Workflow support and design input checks enable an efficient execution and throughput consistently. Since the introduction of our workflow supported change management workflw., we were able to reduce the effort by about 40%. [next slide]
• #21: On this slide, you can see the schema of our structured change management workflow in more detail. Our change management workflow is also very closely tied into the configuration control of instrument prototype data which are used for verification. Further benefits of a standardized change management workflow are as follows: Integration of engineering problem reports encountered during development e.g. software defects, reliability issues of the instrument. Product quality KPIs which can be derived from the existing data set available. [next slide]
• #22: The 3rd challenge we have encountered is all about managing change across Engineering disciplines. It typically takes a multi-discipline team effort and information access to multiple sets of data: Performance engineering reports, defect data, simulation data, … and so forth. By structuring product development data along the product structure itself in a clear and concise way (along a product model), relevant functions in the R&D team have access to the data they need in order to process change requests, check out configuration control data of instruments and as well as design knowledge is captured where it is needed. Just to keep in mind, to enable such a workflow requires a very tight integration of development tool chains. [next slide]
• #23: There is a specific challenge that you face when you are executing configuration management between Engineering and Manufacturing. How do I consistently synchronize Engineering and Manufacturing to become faster and less costly? In order to achieve that, we have borrowed an idea from software development which is to have a controlled way to merge change sets after testing into the main software branch. Instrument development historically has developed various generations of instrument prototypes (with higher functionality and design maturity). Design defects were found were fixed in the next generation, that led to an increase of technical issues to fix. In the current project, we have approached that in a different way, we are chaining the processing of change requests, approved by a CRB together with the design solution and then upgrade an instrument prototype in a manner which is an ongoing activity. That does not only mean that a bill of material needs to be updated, but also instruments need to be kept in synch to know what content (HW, FW, SW) is on an instrument. Additionally, the updated bill of material is then shared with the manufacturing team which knows about the changes very early on and then can it be put into the manufacturing ordering system. Traceability of changes and transparency is maintained. The presented approach has shown to be very effective. [next slide]
• #24: So let’s summarize the main points of this talk on Configuration Engineering: Development of CE needs diverse engineering perspectives along the product development lifecycle (up- and down-stream). Due to little prior published body of knowledge on CE, start at a point in a project that supports showing value to project stakeholders. Lay out an end-to-end vision for where CE can add value and has to lead the path. For a multi-disciplinary domain such as IVD, select a tool-chain which allows as many stakeholders as possible to collaborate within the same workspace. CE based on our own experiences needs to grow over time delivering short-term gains to build credibility while keep the grand vision in place. Thank you for your attention and time! Let’s open the floor for questions.