MEMS Tech Transfer Guide Wiki


2pages on
this wiki
Add New Page
Add New Page Talk0

Welcome to the MEMS Tech Transfer Guide WikiEdit

Scope Edit

The goal of this Wiki guide, which was created by MEMS & Sensors Industry Group and our members, is to be an initial guide/starter for companies developing MEMS devices and includes pointers to more detailed information about each topic. The wikia gives users a list of topics (“things to think about”) that they should keep in mind to address and discuss with their teams and technology transfer partners as they are ramping up production. The guide is not meant to be all-inclusive, and companies should be able to modify it to adapt to their own individual needs.

A successful transfer involves much more than the actual technical transfer itself. An overview of the guide and a deeper definition is provided in the Overview section.

Audience Edit

This guide is primarily for companies that have a proven, predictable & repeatable MEMS or sensors device design, and is not focused on initial device development. However, smart companies that have a proof of concept or prototype with a goal of repeatability ultimately resulting in a high-yield design will also benefit from the information contained within. These companies may include:

  • Established startups 
  • Vertically integrated companies (with internal R&D) that are looking to outsource – looking for partners 
  • Companies interested in second source or capacity expansion activities.
  • Companies acquiring or transfering technology ownership

Others in the MEMS ecosystem that may supply services or be Tech Transfer partners or receptors may also find this guide useful such as

  • Consultants
  • Foundries

Finally, those looking to start companies or university spinouts may "plan ahead" by using this guide.

Benefits of this Guide Edit

Tech transfer can be a bottleneck in the development of a MEMS product and time to market can be severely impacted if too much time is spent in tech transfer. We hope the information contained in this guide may help users to increase the probability of success within budget for their transfers and to help shorten engagement time. Some of the principles described within the guide may help prevent misunderstandings and help set and align expectations between tech transfer parties, fostering a positive business relationship by bringing up issues before they become problems. The material may also be useful for planning and as reference material. Companies may also leverage best practices described here and benefit from the experience of those that have “been there and done that” and escape typical traps.

Background - Tech Transfer Definition Edit

Commercialization of MEMS often requires moving technology from one party to another,hence tech transfer is a part of the process of making MEMS work. Tech Transfer, for the purpose of this wikia, is the process of taking a MEMS device design including designs developed at a commercial fab, university, or start-up, to manufacturing using an external partner (or a different group in the same company). In many cases the transfer could be Fab-to-Fab, but line-to-line may also apply. The guide will consider designs that work at the system level (proven) and can be built with confidence with priority given to the transfer of “high yield designs” (predictability, repeatability) over prototypes, processes or design concepts.

Some level of proof that the design is viable for production is required for this guide to be useful. Earlier phases in the innovation cycle of new MEMS related products, their development procedures, roles, deliverables and necessities are described as part of the product development cycle [2]. This guide keeps in mind that yield/cost requirements may vary a lot depending on application and industry segment and recognizes that a low volume, high cost product might not need the same level of maturity as a high volume consumer product. The Tech Transfer discussion will cover both high and low volume applications and how volume affects approaches, effort and expectations.

Tech Transfer often involves bringing up a technology at a new location, on new equipment, and/or with new people. This guide covers mainly process and production transfer. This initial guide does not cover new equipment technology, new materials or new design technology although these may need to happen to achieve the overall goal of product manufacturing tech transfer. Tech Transfer may lead to new research to solve problems but the goal is transfer of a “known good” technology.

An opportunity for Tech Transfer exists at every stage of MEMS product development as evidenced in the MEMS Development Cycle and Foundry schematic (show link). As described above this guide will initially focus on the process/production aspect of tech transfer. But one can broaden the definition to selling an idea/design/IP/technology and transferring it externally or to prototyping (in and out-of-house).

This guide will not initially cover these topics per se but the information in this Wiki may be useful to these endeavors and in future versions of this Wiki we will tackle these very relevant issues for MEMS companies.

Guide Edit

Overview of Tech Transfer Topics Edit

Tech transfer involves a variety of activities, agreements and information transfers that will hopefully lead to a positive result for both parties involved in the transfer.

The goals for tech transfer should be clear to both parties and what constitutes a successful outcome should be clearly defined before the transfer is started. This issue is addressed here.

  • A broad range of technical issues will be addressed during tech transfer, some important challenges and issues are listed here.
  • The parties involved in the tech transfer will have to work together smoothly to be successful. It will be important to identify clearly the roles of the various personnel on both sides. Some of the personnel and their roles in tech transfer are described here..
  • Both sides should also collaborate on a written tech transfer plan involving Tasks, Schedules and Milestones as addressed here.
  • In order to proceed with the transfer, a series of documents will be exchanged, some of these documents are described here.
  • Of special concern are IP/legal issues as described here.
  • The MEMS Ecosystem is available to help with tech transfer. A number of consultants provide services to guide tech transfer and have "Done it before". Companies also offer products to support tech transfer such as CAD Tools, Planning Tools etc. Many companies in the MEMS ecosystem are members of MEMS & Sensors Industry Group, the non-profit trade association advancing MEMS and sensors across global markets.
  • Finally, best practices and examples are available to help, a brief collection is given here.

How to Know if You Have a Production Ready Design Edit

What is a “production ready” design? (in other words “Are you ready for tech transfer?”, what does it take to be ready)

  • Why and when does something need to be transferred?
    • The Product Development Stages section of the MEMS Foundry Engagement Guide describes 4 areas of product development:
      • 1. Proof of concept: A design/model exists but the new device is only proven at the lab level if at all.
      • 2. Functioning prototype: Sufficient quantities to start evaluation of performance variance, system integration, and packaging.
      • 3. Pilot product: The device design and process flow are established and stable.
      • 4. Mature product: Device design and process flow is fully qualified.
    • The Tech Transfer guide is best suited for companies that are ready to move into Pilot level produciton and at least have a functioning prototype with a stable process.
  • What is a “production ready” design?
    • Please visit the Self Evaluation Checklist section of the MEMS Foundry Engagement Guide to determine if you are ready to approach a foundry with your design which is the first step before technology transfer.
  • How to know when you are ready to transfer to a foundry?
    • Your company is ready to transfer production to a foundry if all criteria below are met.
      1. Your company has a stable process flow and mask set
      2. You are prepared to spend over $1 Million USD/year just for foundry expenses
      3. You have an order schedule which describes how many wafers you plan to buy over the next 1-2 years
      4. You have determined cost targets for wafers or die
    • Your company is NOT ready to transfer to a foundry if:
      1. Your company is still exploring the physics of your devices and trying to improve them significantly
      2. You need Design of Experiments to characterize your device behavior (i.e. many design variants)
      3. You don’t yet fully understand what design/process conditions create a “good” device
      4. Your company has not yet secured at least $1 Million USD in funding (just for MEMS fabrication
  • Rookie Mistakes
    • Potential pitfalls/mistakes to be avoided for first time tech transfers are as follows:
      • Only getting a quote from one foundry
      • Expecting the tech transfer process to be completed and be production ready in less than a year
      • Not presenting a good RFQ or business case. Please see the section on How to Write an RFQ in the Foundry Engagement Guide.
      • Twiddling design/process while wafers are in progress
      • Being underfunded
      • Lack of communication with your foundry

Please see the MEMS Foundry Engagement Guide for a list of criteria of [Foundry Engagement Guide Wiki#A guide to how a foundry selects customers|how a foundry selects its customers.]

Roles, Team, and Collaboration strategies Edit

The MSIG Technology Development Process Template [3] provides a high level view of the roles and requirements for MEMS technology development.  The tech transfer team must validate the technology characterization on the new line.  Pending the level of characterization prior to transfer, the similarity of equipment between facilities (including test methods and operational practices) the complexity of transfer can vary and greatly affect the amount of time and type of resources needed.

A "copy exact style transfer" has less risk though is usually only applicable for very high volume products or second sourcing strategies. Many MEMS tech transfers require substantial re-characterization of process steps to obtain stable, yielding results. Process development, redesign and the corresponding integration efforts may even be necessary when using dissimilar equipment. There may be serious interactions as a result of subtle differences between the lines that may not be foreseen. Assess risk thoroughly, test high risk issues early and keep the initial technology development team engaged to mitigate risk along the way.

Below is a list of considerations

  • What type of product is being transferred:
    • Design related
    • Process related
    • Both
  • Structure of the IP and the implications on the team and role (process IP, design IP)
  • Approach for transferring – copy exact; copy end performance, etc.
  • Are you providing or receiving - process, design, know-how
  • How many partners are involved? Bi-lateral, tri-lateral...
  • Is the partnership traditionally grown, adhoc or strategically planned?
  • Is it an ongoing relationship? Does it need to work for the long term? What would justify the reason(s) for it to be short-term? What problem(s) is a short-term relationship solving?
  • Set a precedent for future collaboration
  • Who are you transferring to:
    • Lab to Fab
      • Internal Fab
      • External Fab
    • Fab to Fab
      • Internal Fab
      • External Fab
  • What is the technology readiness level of the technology?
  • What are the different models of interaction/collaboration- examples of models for tech transfer – these are the spectrum (opposite sides of spectrum)
    • Spec oriented model (ASIC model) (more hands off, not in the fab)
    • Joint development approach with interaction to a certain level
    • Process oriented, collaboration model (boots on the ground in the fab)

For the later two indications for the steps, business processes, roles, deliverables etc. are given in [2], [4]

  • Set a clear framework for discussion
  • Who should be on the team? (organization wise, person wise)
  • Alignment on development / collaboration methodology, sync points, infrastructure... also see [2], [4] for indicators
  • Don’t partition the process from design, technology from product development.
  • Collaboration methods- embedded personnel? As MEMS increasingly moves into mainstream IC foundries it becomes very difficult to embed technical boots on the ground with fab access. Does this suggest the skill set of a MEMS process transfer project manager? Might need a shift in skills and experience.
  • Conflict resolution-problem solving, escalation processes; best is to agree an stand business process from project management methodologies as in PMBOK or Prince2. Later is used in [2] to define a holistic set of business processes for joint development approaches
  • Innovation and collaboration while maintain rights, trade secrets, IP (need IP framework) See also section- This is key and needs to be decided up front. How is new, foreground IP handled, how are trade secrets handled (in the context of the NDA between parties) etc. This agreement will color most of the aspects of the relationship including how well and freely information is shared. As a result, it can directly impact the time line, cost, and ultimate success of the transfer.
  • Knowledge of process and design mistakes are invaluable. Leverage the history (documentation and people); see infrastructure How to capture? How to transport? Level of ownership? In [2] the aspects of knowledge management are discussed and an example infrastructure given, today commercially available [5], [6].
  • General hints:
    • Leverage staff with hands-on experience
    • Boots on the ground” is good (face to face contact and side-by-side working if possible)
    • Brains beat documents almost every time, unless they walk out of the doors. Establish information and knowledge capture approaches (electronic information beats documents and brains by far) [5], [6].
    • Pictures and images (history, mistakes, examples) are critical to success - therefore use infrastructure to seamless capture / share and transfer [5], [6].
    • Don’t ignore the inputs just because you have more experience. (Prevent the "not invented here" syndrome)
    • Make sure to get the sides together as often as needed.
    • The Key is to leverage the incentives, strengths and expertise of the interested parties to maximize success.
    • Make sure that everyone is gaining something from the collaboration.

Expectations and Responsibilities Edit

  • Lay out clean/clear communication guidelines for tech transfer re. responsibilities of each party (especially important on fab-side); create a checklist
  • Expectations and priorities of both sides of the transfer need to be aligned
  • Ongoing process - Need to return to the list of expectations/responsibilities
  • Project management approach /method; creation of joint program steering committee
  • How can you incentivize all parties to engage for maximum success?

What is Success? When are we done? Edit

  • Companies may have the wrong expectations around the end point
  • Creating clear, quantifiable and measurable milestones to avoid “creep”
  • Quantitative measures for success should be agreed upon up front, but are generally further out than the parties initially assume.
  • MEMS design and development isn’t done until the design has successfully transferred into production. If you can’t make it at sufficient yield to meet your requirements, it’s not done.
  • Fab transfer is not done when first samples are completed.
  • This is only the first main milestone of transfer.
  • Transition of a design or core technology may be a one time event.
  • You are done when the process works or the prototypes are replicated for the first time.
  • In the production context, success may be measured in yield or volume/capacity met.
  • Can the back-end impact the success of a tech transfer in the foundry?  Focus on producing the final product in final format and qualifying that.
  • A good tech transfer is never “done.” 
  • It is only the first step of the next development activity.
  • The specifics may depend on the product requirements, but in the end the main measure is whether you can build what you need in sufficient volume and at a cost point to support the market.

IP/Legal Edit

IP management is critical, but overzealous pursuit of IP can be an innovation and collaboration killer. How do you maximize openness and collaboration while protecting all parties? While it may be true that extreme overzealous pursuit of IP can be an issue, the far greater risk is undervaluing one's IP. Protecting those ideas that provide one a competitive advantage is not just desirable, it is critical and that protection should be viewed as valuable to a partner as well. Each party entering in to an agreement should already understand that the other side needs to control IP they've already developed. Further, it is in each party's interest that the other survives (and flourishes from) the collaboration. A strong partner has great value. A weak partner is a potential liability if, down the road when needed, they go away because of an inability to protect their competitive position. So, even though IP issues can be a burden to open collaboration, good management of IP can clear the path for a successful collaboration.

How are IP rights typically partitioned? What is the value of Joint IP vs. IP partitioning?

  • A typical IP split is that the foundry retains rights to process IP and the customer retains their design IP but often this split cannot be maintained as the foundry may have design suggestions and the customer may come in with process information or make suggestions. Set boundaries and partition areas of expertise. (A clear understanding of what aspects of the joint effort is important to each party is critical). Identify the strengths of the parties and be sure to claim your own.
  • There is a general feeling that is best to avoid joint IP
  • It is critical to understand that each owner of jointly owned IP has unilateral rights and can do whatever they want with the property (e.g. license to anyone, sell to anyone, etc.) WITHOUT requiring approval by the other owner or owners. Further, neither party needs to account to the others or share revenues derived from licensing or sale of the jointly owned IP.

What agreements should be drawn up and what should be in them?

The parties should discuss the framework for their agreements and documentation – what’s in scope, out of scope and where you “draw the line”; how much you want to document and record; notifications between the parties; management of IP filings and ownership. Know your partners and understand their motivations and needs. Come in the door with a clear summary of what you are bringing to the table. It isn't enough to have this understanding in your own mind. A document outlining what has already been developed by your organization prior to entry into a joint effort is critical. If possible, provisional applications should be filed on any subject matter deemed critical to an organizations efforts (and survival).

An IP document should include:

  • Areas of exclusive rights that each party retains
  • Areas of commercial rights that each party maintains - e.g. one party might cede all rights for medical applications only, but retain them in all other (or some defined) areas
  • It is advisable that key technical terms used to reserve areas of exclusion be clearly defined in a manner agreed upon by both parties
  • JDA's and similar agreements are typically negotiated when parties are happy with one another. They MATTER, however, when the parties are threatening lawsuits. It is critical, therefore, to make sure that any terms important to you are reflected in the language agreed upon in writing UP FRONT.

Technical Issues Edit

This Wiki does not address design transfer except as it relates to the fact that design may need to be changed as the fabrication process is migrated or determined. Specifically, a discussion between the tech transfer parties should be had to determine how the process and design are related/dependent and how problems in design discovered during transfer and how problems in fab requiring design changes will be handled.

There are many technical challenges/issues to be addressed during tech transfer- a check list of items that should be discussed between parties is

  • Challenges
    • Equipment Match- is the fab's equipment set compatible with that used to bring up the original design
    • Suppliers Match- are the supplier's used by the fab compatible with those used to bring up the original design
    • Materials Match- are the all of the materials available at the fab that were used to bring up the original design
    • Process changes- what process changes if any are required due to the new fab's policies, experience
    • Unit process/sequence match-Do the unit processes match or does the new fab propose a different set of processes and sequence
    • Production Scaling-does the fab have the capacity to run the needed amount of wafers?
    • 2nd Line or 2nd source-does the fab provide or have a second source or will there be a need for another transfer
    • 6” to 8”-does the fab have matching wafer sizes to that used to bring up the process

Best practices Edit

  • How can we learn from past experiences in industry and is there a better way?
  • Best practices will be added to this guide as they are developed.
  • Test Early, do your failure analysis
  • Detailed, documented description of deliverables
  • Clear set of quantifiable, measurable, and relevant milestones and method to monitor
  • Up-front IP ownership and information sharing agreements.

Contributors Edit

MEMS & Sensors Industry Group (MSIG) would like to that the following controbutors to this wikia. If you are interested in becoming a contributor and sharing your own knowledge, please contact Andy Knopes at for more information.

  • Mary Ann Maher, CEO, SoftMEMS, Committee Chair
  • Ralf Dudde, Strategic Planning/Product Development, Fraunhofer ISIT
  • Alissa Fitzgerald, Founder and Managing Member, AM Fitzgerald & Associates
  • Jeff Hilbert, President, WiSpry
  • Valerie Marty, MEMS Integration Engineer, HP
  • Peter Merz, MEMS Business Unit Manager, X-Fab MEMS Foundry
  • Dirk Ortloff, Project Manager XperiDesk, CamLine
  • Jason Tauscher, Director MEMS Development, MicroVision
  • Jim Walker, Patent Agent, Kaplan, Breyer, Schwartz, & Ottesen, LLP (KBSO)

References/links Edit

  1. MEMS Foundry Guide Wiki
  2. 2.0 2.1 2.2 2.3 2.4 MEMS Product Engineering : Handling the Diversity of an Emerging Technology. Best Practices for Cooperative Development. ISBN 9783709107065by Dirk Ortloff; Thilo Schmidt; Kai Hahn; Tomasz Bieniek; Grzegorz Janczyk; Rainer Brück
  3. Technology Development Protocol
  4. 4.0 4.1 Technology Development Protocol
  5. 5.0 5.1 5.2 Converting data into information
  6. 6.0 6.1 6.2 Recurring deficiencies in process development support
8. AMFitzgerald | Custom MEMS Development

9. Berkley Sensor & Actuator Center (BSAC)

Future Work Edit

  • Overall Checklist
  • Additional Sections
    • Documentation Section
    • Tasks, Schedules, Milestones, Budget issues
  • Examples/Case Studies/Best Practices
  • Additional References/Links

Latest activity ===

Photos and videos are a great way to add visuals to your wiki. Find videos about your topic by exploring Wikia's Video Library.

MEMS & Sensors Industry Group logo

Also on Fandom

Random Wiki