Industry News, Trends and Technology, and Standards Updates

Yufeng Huang of Cimetrix China, talks about Equipment Control in the factory. Read now in Chinese or below in English.

在和半导体设备制造公司的接触中我们遇到这么一个尴尬的问题，很多懂得设备控制的优秀软件工程师对于GEM，GEM300和EDA标准不是很有经验。这些公司往往是在设备在实验室研发成功，准备产业化送入客户工厂时发现设备没有实现或只有部分实现GEM/GEM300标准，尤其是当客户工厂要求EDA（Interface A）通信接口的时候，这些设备制造商的软件工程师往往一脸茫然，不知道如何在短时间内开发出完全遵循GEM/GEM300/EDA标准的软件。

对于大多数设备公司而言，限制于有限的人力、财力资源，公司很难聘请到足够多富有经验的工厂自动化软件工程师开发自己的GEM/GEM300，甚至EDA软件模块。另外一个棘手的问题是我们发现很多软件工程师不是特别有意愿加入到半导体行业，而是选择比较热门的互联网、游戏，手机App等软件行业。纵观半导体工厂自动化软件市场，虽然已有多家公司提供GEM/GEM300/EDA的软件开发包（SDK），但软件工程师仍旧需要掌握一定的工厂自动化基础知识才能着手编写软件集成代码。工厂自动化涉及大量SEMI标准，譬如GEM标准大概有450页文档，包括E4，E5，E30，E37，E37.1，E172，E173，GEM300标准大概有280页文档，包括E39，E40，E87，E90，E94，E116，E157，E148，而更为复杂的EDA标准大概480有页文档，包括E120，E125，E128，E132，E134，E138，E164，对于大多数非专业的工厂自动化软件工程师而言，工厂自动化软件的集成工作是一件极其繁琐而艰难的任务。

Cimetrix Control Framework^TM (CCF) 是基于微软.Net技术的设备自动化控制软件框架，该软件不仅为设备制造厂商提供了监督控制和生产控制框架代码，而且完全实现了GEM/GEM300/EDA标准。借助CCF软件平台，软件工程师无需深刻掌握工厂自动化的所有SEMI标准，就能轻松变身为工厂自动化开发专家。CCF软件框架内的工厂自动化模块基于Cimetrix公司的CIMConnect，CIM300，CIMPortal Plus三个独立的软件开发套件（SDK）实现，分别对于实现GEM，GEM300，和EDA标准。全球任意一家300mm的芯片制造工厂都有安装了CIM300软件的设备运行，在支持EDA数据采集的工厂都有安装了CIMPortal Plus软件的设备运行。CCF软件框架将所有工厂自动化的开发工作交给Cimetrix公司来完成，设备软件工程师可以把更多的时间花费在如何设计自己的设备控制软件上。

在CCF框架下，CIMConnect/CIM300/CIMPortal Plus的底层API函数都被很好作了封装，软件工程师只需通过CCF框架提供的函数或接口就能轻松实现和工厂主机程序的所有GEM/GEM300标准。实现EDA标准的一个重要任务是创建一个支持分层次结构的设备模型，以及按照标准生成XML数据，此外生成的模型还需满足E164标准。在CCF软件初始化运行时会动态生成设备模型，软件工程师几乎不需要书写EDA代码，设备即可很好的遵循EDA标准。

采用CCF软件框架降低设备控制程序和工厂自动化程序的开发难度和开发周期，但并不意味着我们的客户一定得推翻自己已有的软件平台或已经测试过的稳定代码。CCF是一个提供源代码的完全开放的自动化控制程序框架，你可以将CCF理解成一个已经拼好的乐高玩具，用户既可以将自己的代码模块集成到CCF中，也可以挑选部分CCF功能模块并将其转移到用户自己的框架中。我们用户将CCF中工厂自动化模块（包括GEM/GEM300/EDA）搬迁到自己的程序框架中，在保证完全遵循工厂自动化诸多SEMI标准的同时，对用户已有程序的影响非常小。

得益于CCF框架的完全开放性，像玩乐高积木一样，软件工程师可以轻松享受自由裁剪自己想要的控制系统框架带来的乐趣，这是其他任何一家提供设备控制软件框架程序的公司都很难做到的一件事情。

在未来几年，越来越多的工厂往智能生产制造的方向发展，由此对数据的需要越来越高，EDA标准越来越成为工厂主流的数据采集方法，CCF无疑成为了设备制造商更快更好实现各种工厂自动化标准的最佳武器。 

---

We encountered an interesting issue when working with semiconductor equipment manufacturing companies. Many excellent software engineers who know equipment control are not very experienced with the GEM, GEM300, and EDA standards. Sometimes after equipment is successfully developed in the laboratory and before the equipment is shipped to the factory, we discover that the equipment did not implement or only partially implemented the required GEM/GEM300/EDA standard. This is especially prevalent when the factory requires the EDA (Interface A) communication interface. Equipment software engineers sometimes do not know how to develop software that fully complies with GEM/GEM300/EDA standards in a short period of time.

For most equipment companies with limited human and financial resources, it is difficult for the company to have the resources to develop their own GEM/GEM300/EDA software. Another issue is that we have found many of the more experienced software engineers are more interested in high-profile  internet, gaming, mobile phone apps and other software industries rather than the lower profile semiconductor industry.  Although many companies in the semiconductor factory automation software market have provided GEM/GEM300/EDA software development kits (SDKs), software engineers still need to master certain basic knowledge of factory automation to start writing software integration code. Factory automation involves a large number of SEMI standards. For example, the GEM standard has about 450 pages of documents, including E4, E5, E30, E37, E37.1, E172, E173. GEM300 standards have about 280 pages of documents, including E39, E40, E87, E90, E94, E116, E157, E148. The more complex EDA standard has about 480 pages, including E120, E125, E128, E132, E134, E138, E164. For less experienced factory automation software engineers, the integration of automation software can be an extremely tedious and difficult task.

Cimetrix CIMControlFramework^TM (CCF) is an equipment automation control software framework based on Microsoft .Net technology. This software not only provides equipment manufacturers with supervisory control and equipment control framework code, but also fully implements the GEM, GEM300 and EDA standards. With the help of the CCF software platform, software engineers can easily turn into factory automation development experts without having to master all the factory automation SEMI standards. The factory automation components within the framework of the CCF software are based on CIMConnect, CIM300, and CIMPortal Plus, three independent software development kits (SDKs) from Cimetrix for the implementation of the GEM, GEM300, and EDA standards, respectively. All 300mm chip manufacturing factories in the world have equipment installed which uses CIM300 software. Any factory requiring EDA data collection has equipment installed that uses CIMPortal Plus software. With the CCF software framework, Cimetrix has already done the work of integrating all factory automation into the framework. The equipment software engineer can spend more time on how to develop their own equipment control software.

Under the CCF framework, the underlying API functions of CIMConnect/CIM300/CIMPortal Plus are well encapsulated. Software engineers can easily implement all the GEM/GEM300/EDA standards of the factory host program through the functions or interfaces provided by the CCF framework. An important task in implementing the EDA standard is to create an equipment model that supports hierarchical structures and generate XML data in accordance with standards. In addition, the generated model must also meet the SEMI E164 standard. The equipment model is dynamically generated when the CCF software is initialized. The software engineer needs to do very little to have an equipment control application that is fully compliant with the EDA standard.

The use of the CCF software framework to reduce the difficulty and development cycle of equipment control programs and factory automation programs does not mean that our clients must replace their existing software platforms or stable code that has been tested. CCF is a fully open automation control program framework that provides source code. You can think of CCF as a LEGO toy that has been put together. Users can either integrate their own code modules into CCF or select some of the CCF functional modules and transfer them to their own framework. Our clients can reuse the factory automation modules (including GEM/GEM300/EDA) in CCF in their own program frameworks. While ensuring that all SEMI standards for factory automation are fully complied with. The impact on the user's existing programs is minimal.

Thanks to the complete openness of the CCF framework, like LEGO bricks, software engineers can easily enjoy the freedom of tailoring the control system framework that they want. It is hard for any company that provides an equipment control software framework program to implement such a rich library of functions. 

In the next few years, more and more factories will move in the direction of smart manufacturing. As a result, the demand for data is getting higher and higher. EDA standards are increasingly becoming the factory's mainstream data collection method. CCF will undoubtedly become the best weapon for equipment manufacturers to quickly and completely implement the various factory automation standards.

As part of the CIMControlFramework (CCF) product for creating equipment control applications, Cimetrix developed a logging package. Our logging package has two parts – collecting the log messages and analysis of the messages.

The logging package allows you to assign a source and a type for each log message. The source specifies where the log message originated. The type is a category that can be used to route the log 

messages to specific output locations called log sinks. We have found the most useful log sink to be a text-based log file. The logging package can be configured for the types of messages to log. It can also be configured for how long to keep log files and how many to keep. This helps keep hard drives from getting too full.

One of the habits outlined in Stephen R. Covey's book, The 7 Habits of Highly Effective People, is to "Begin with the End in Mind." He goes on to explain that beginning with the end in mind means to "begin each day, task, or project with a clear vision of your desired direction and destination, and then continue by flexing your proactive muscles to make things happen.”

Beginning an equipment control project with a clear vision of your desired destination makes it much more likely that you will have a successful project. A blog post titled CIMControlFramework Work Breakdown dated March 15, 2016 outlined the tasks necessary to create a first-class equipment control application using CIMControlFramework (CCF). Since that initial blog post, Cimetrix has explored each of the tasks labeled in the work breakdown structure in greater depth in their own blog posts as follows:

• Integrate devices – Create Device Drivers Using CCF
• Material movement through the tool – Create a Scheduler Using CCF
• Implement the process module – Implementing Your Process Module Using CCF
• Create an operator interface (OI) – Create Operator Interface Screens Using CCF
• Simulation – Testing Your CCF Application without Waiting for Hardware
• Recipes – Designing Recipes in CCF
• I/O – Using CCF IO Helper Functionality
• Data collection and storage – Storing Data in a CCF Application
• Factory Automation – CCF Provides Fully Implemented GEM300 and EDA Interfaces
• Diagnostics and Testing – This information was provided previously in a two-part blog regarding the benefits of logging. Read Part 1 (Logging - enabling passionate support) and Part 2 (CIMControlFramework Logging Benefits).
• Errors and recovery – CCF provides an Alarms package for signaling of and recovery from error conditions.

Looking back from the successful completion of a CCF equipment control application makes it clear that the work breakdown vision from the beginning helped gain that success.

You can also reference the following blog posts related to CimControlFramework:

CIMControlFramework Dynamic Model Creation

Learning from Others

Build vs. Buy

WCF and CIMControlFramework

To learn more about CCF, visit the CIMControlFramework page on our website!

You've heard the expression, “you can’t make an omelet without breaking a few eggs.” That is, you shouldn't be surprised if you end up destroying a few things in the process of achieving your goal. When it comes to building a new piece of equipment, do you really want to risk breaking a few wafers, or worse yet, hurting personnel or equipment, to develop your new tool control software? I think everyone would answer with a resounding “No!”
In the March 2016 blog post on CIMControlFramework Work Breakdown, simulation was listed as one of the eleven points to be taken into consideration when developing an equipment control application using CIMControlFramework (CCF). In addition to personnel and hardware safety, there are other reasons to use simulation when developing equipment control applications, namely:

• You want to start testing your software as early as possible, often this is before your equipment is finished. Then when your equipment is ready, integrating your tested software with your hardware will proceed smoothly and minimize delays in your time to market.

• If you have an existing tool and you’re upgrading your tool control software, scheduling software testing time while still allowing other engineering teams (mechanical, process, etc.) to get their jobs done is challenging.

• The hardware components that comprise your tool, e.g. robots, load locks, and process modules, will not be finished at the same time. You want to test your software with real hardware as soon as possible, while still simulating the missing equipment components.

• Tool time is valuable. It's nice to be able to test your software without using the valuable tool time where possible.

• It is likely that your tool will have more than one configuration, customized for each of your clients. Setting up different hardware configurations in order to develop and test your tool control software is time consuming. You want to be able to test your software for all of your equipment configurations in timely manner.

CCF provides a simulator that you can use to test your tool control software during development, and before you run the software on the real hardware. Running against a simulator first will expose issues in your software without damaging people, material and hardware. CCF’s simulator simulates real hardware, which means it is not necessary to add conditional checks in your software to check when it is running with a simulator versus real hardware.

CCF’s simulator features include:

• Simulation of atmospheric and vacuum hardware components, e.g. load locks, vacuum pumps, vacuum gauges, etc.

• Simulating delivery and removal of carriers to load ports, both manually and automatically using E84 handshaking.

• Simulation of robot moves for both atmospheric and vacuum robots.

• Simulation of I/O.

• Simulation of hardware faults, to safely test error handling.

• Simulate running single jobs or cycling wafers for endurance testing.

Additionally, CCF provides other tools to help you test your software without hardware.  CCF provides a Visual Studio template, and a number of classes and interfaces to aid you in developing simulation software for your process module or other custom hardware. Use the Visual Studio template to start development of GUI user controls for simulated hardware. Implement CCF’s I/O simulation interfaces for generating inputs to your tool control software and writing outputs to your simulated hardware. Tie the two sides together using CCF’s simulation client and server to handle the communication.

With these CCF tools, you can develop and test your tool control software without hardware. When hardware is available, you can test your software with your tool with a high degree of confidence that it will perform as expected.

Avoid “breaking a few eggs” and develop your tool control software with CCF and test it using CCF simulation features.

To learn more about CCF, visit the CIMControlFramework page on our website!

“Can you hear me now?”

A Cimetrix blog post on March 15, 2016 entitled “CIMControlFramework Work Breakdown”mentions that CIMControlFramework (CCF) includes ASCII serial drivers and IO providers.  What does that mean and why should you care?

Equipment automation is all about creating software that controls hardware—combining individual components into a harmonious whole, with each piece playing its own unique part.  A critical aspect of control is the ability to communicate—and that is where CCF’s ASCII serial driver and IO providers can help you create your equipment application.

The .NET Framework, like many software development platforms, provides built-in support for serial ports and TCP/IP ports.  This built-in support is great for low-level, binary communication, but hardware devices often just need a simple ASCII connection.  For such hardware, CCF’s ASCII serial driver frees you from worrying about the connection and the underlying implementation.  You can focus on the content of the message instead of the mechanics of delivery.  It’s like using a telephone—you want to focus on the conversation rather than worrying about how the sounds are transmitted between the phones. 

Another common class of hardware uses signals to communicate.  These signals can be as simple as only having two possible values (think “on” and “off”) or having a range of values, like a temperature.  Each signal also has a direction—it is either an input or an output.  For input signals, the value is determined by the hardware and read by the software.  Output signal values are determined by the software and sent to the hardware.  For example, control software might use an output signal to turn a light on and off, and an input signal from a photocell to verify the light is on or off.  This class of hardware is called I/O (short for input/output) devices and is supported by CCF.

CCF includes support for communicating with ASCII serial and I/O devices to make your job easier.  Don’t spend your time and effort asking the hardware “Can you hear me now?”  Use CCF and focus on combining the parts into the harmonious whole. 

To learn more about CCF, visit the CIMControlFramework page on our website!

In Sir Arthur Conon Doyle’s A Scandal in Bohemia, Sherlock Holmes tells Watson, “It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

In a March 2016 blog post on CCF work breakdown Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the tasks in the work breakdown is to determine what kind of data collection and storage is to be used in your CCF application and determine how that data is to be stored.

CCF provides several mechanisms for collecting and storing data. These include:

• History Objects

• Full GEM Interface

• Full EDA/Interface A Interface

• Centralized DataServer

The remainder of this blog post will look at each of these items in more detail.

History Objects

In early iterations of CCF, users noticed when using logging, there were certain messages that they wanted to be able to query without the overhead of having to search all log messages. To help accommodate this need, History objects were introduced. Some examples of these objects in CCF are EPT History, Wafer History and Alarm History. When an important event happens in the life of a history object, a log message is written to a database table (configured during CCF installation) that corresponds to that type of object. That database table can be queried for the specific historical information for only that type of data. 

Full GEM/GEM 300 Interface

As described in a CCF blog post from February 15, 2017, CCF comes standard with a fully implemented GEM and GEM 300 interface. The GEM standards allow users to set up trace and event reports for the collection of GEM data. No additional programming is required by the application developer to have access to the GEM data collection.

Full EDA/Interface A Interface

The same blog post of February 15th also states that CCF comes standard with a fully implemented Freeze II and E164 compliant EDA interface. EDA can be used to set up data collection plans based on Events, Exceptions and Traces. With the E157 standard and conditional trace triggers, EDA makes it easy to zero in on the data you want without having to collect all data and then sift through it later.

Centralized DataServer

In order to create, initialize, populate and pass data, CCF uses a centralized DataServer object. The DataServer is responsible for creating the dynamic EDA equipment modelas well as populating CIMConnect with Status Variables, Data Variables, Collection Events and Alarms. All this is done at tool startup so that the data available exactly matches the tool that is in use.

Data is routed to the DataServer which then updates the appropriate client – such as EDA, GEM or the Operator Interface. An equipment control application can register to receive an event from the data server when data changes. Users can key off of this event to capture that data and route it to a database as desired. Since all tool manufacturers have different requirements for which database to use and how data is written to that database, CCF leaves the actual SQL (or equivalent) commands for writing the data to the equipment application developer.

With CCF Data collection and storage is … Elementary.

To learn more about CCF, visit the CIMControlFramework page on our website!

What does this mean and why should I care?

The SEMI standards for 300mm Semiconductor Manufacturing Equipment can be an overwhelming burden of information to understand, let alone implement.

The GEM standards comprise over 450 pages of documentation: E4, E5, E30, E37, E37.1, E172, E173.

The 300mm standards add another 280 pages: E39, E40, E87, E90, E94, E116, E157, E148.

And the EDA standards pile on an additional 480 pages: E120, E125, E128, E132, E134, E138, E164.

That’s over 1200 pages of standards documents filled with requirements and implementation information. 

On top of that GEM and EDA collect data differently from the equipment.  See a post we did on data collection for more information on those differences.

Implementing the requirements defined in those standards without an SDK would be a very brave undertaking.  Even with SDKs for the standards, it would be a fair amount of work, when all you really want to do is get your equipment automated.

In addition, it is very important that those standards be implemented correctly in order for your equipment to be smoothly integrated and accepted into each fab.  Different fabs use the standards slightly differently or have additional requirements.   This requires experience.

GEM300 and EDA standards implementation is a very large burden.

So what does this mean?

One of the large tasks for the EDA standards is defining a hierarchical model of the equipment and what data it can produce in XML per the schemas defined in the standards.   Creating the initial model and keeping it up to date as the equipment evolves is a tedious task.  In addition, that model must be conformant to the E164 standard (which has over 10 pages of requirements on its own).   See our blog post on conformance testing. CCF does this for you, producing an E164 compliant EDA model in the background based on your CCF programming. See our blog post on CCF dynamic model creation further details.  CCF also builds the GEM interface model for you at the same time.

Further, CCF is completely GEM compliant and 300mm compliant, using the Cimetrix CIMConnect and CIM300 products which have been successfully deployed in every 300mm fab around the world on many different equipment types.

Twelve hundred pages of standards, compliantly implemented, at no additional effort.  That is what this means.

Turn that donkey into a goat and use CCF.

To learn more about CCF, visit the CIMControlFramework page on our website!

 

You have designed the ultimate process that will revolutionize the semiconductor industry.  The parts have been collected, the process module assembled.   But now you need the software to make all the components work together.

As described in a recent CIMControlFramework (CCF) blog post around designing recipes, the recipe is the secret sauce for your process.  The recipe is used to direct the hardware to perform the process; How much time in a step, temperature, gas flow, pressure, etc.

The recipe provides directions to the process module on how to perform the processing.  How and when to enable/disable hardware components.  What setpoints to be set for components.  How much time to spend on any given step.  The process module (PM) software that you develop will take the recipe that you have defined and perform the operations using that recipe. CCF stays out of your way to allow to create your secret sauce.  

CCF makes integrating your process module easy.  CCF provides a simple process module interface that allows CCF to know when to prepare for processing, prepare for transfer, and process using the supplied recipe.

 Your process module hardware may be made up of any number and types hardware components, E.g.  Mass Flow Controller(s), valves, chuck, etc. that will be used to process the recipe. Since CCF does not use proprietary interfaces and does use C# and Visual Studio, creating interfaces to your hardware is much easier and left to you to design and develop these drivers. CCF makes it easy to connect to your hardware, whether it is via a PLC or talking directly to the hardware. 

CCF makes it incredibly simple to report data to a UI, a GEM host and even an EDA client.  Declare your status variable, update, and publish.  The data is reported to all three for you automatically!!

CCF takes the stress out of the necessary evil of moving material through the equipment to get it to your process module. It provides an interface for interacting with your process module allowing you to spend your time where it matters most - creating your secret sauce to help make you successful!

To learn more about CCF, visit the CIMControlFramework page on our website!

Anyone above a certain age will be able to tell you what you get when you combine two all-beef patties, special sauce, lettuce, cheese, pickles, onions – on a sesame seed bun. There are many who would argue that what sets a Big Mac apart from other burgers – and has made it one of the best-selling products of all time – is the special sauce.

In a March 2016 blog post, Cimetrix listed eleven points to be taken into consideration when starting an equipment control application using CIMControlFramework (CCF). One of the things to consider is how you want to provide process and path information through the tool using recipes. This blog post delves a little deeper into the recipe aspect of equipment control applications.

In CCF, recipes are either process recipes or sequence recipes.

A process recipe contains the instructions to be carried out by a particular process module. These instructions can range from temperature settings to types of gas to flow. The most important aspect of any tool control application is allowing the tool manufacturer to do what they do best – perform their process better than anyone else in the world. The process recipe allows tool manufacturers to add their special sauce to the wafer. CCF provides a sample process recipe implementation as well as very simple process recipe editor. Since recipes are generally custom for each tool manufacturer, CCF application developers usually want to customize the recipe contents for a process recipe.

If the processing of material is the special sauce, the rest of the application, moving the wafer through the tool, is a necessary evil. To assist in moving material through the tool, CCF also provides a sequence recipe. A sequence recipe determines which process recipes are to be run, at which modules to run them, and the order in which this is to occur. CCF provides a sample sequence recipe editor that can be used in creating sequence recipes or customized for each tool manufacturer’s needs.

Both process and sequence recipes can be created on the tool or downloaded from a factory host. CCF provides a handler that receives recipes from the host and stores them in the Recipe Server. Regardless of where the recipes are created, CCF’s Recipe Server stores the recipes locally and passes them in to the scheduler when a job is to be run. The Recipe Server allows recipes to be stored as Engineering recipes while they are being finalized. They can then be promoted to Production recipes for use in a production environment. 

By making use of recipes in CCF, you can ensure that your special sauce is applied to material processing to help make your tool one of the best-selling in history.

To learn more about CCF, visit the CIMControlFramework page on our website! 

Our bodies are amazing machines. Ask a man off the street what they see when they look at someone, they will probably talk about skin, hair and eye color, height and weight and other external defining characteristics. Ask a doctor and they may see issues relating to what’s going on in the person’s organs and overall internal function. Ask a molecular biologist and they’ll talk about the chemical pathways that allow things to work at the cellular level. Much like our bodies, computer controlled systems are made up of many layers. Starting with electrons moving through conductive and semi-conductive materials, abstraction layer is added upon abstraction layer to create components, circuits, assemblies until finally a computer is created. In the same way layers of software control this computer from the BIOS up through layers in the operating systems and culminating in the application the user sees. Similar to the way doctors and biologists work at different levels of abstraction within their domains, we as engineers know about, work with and think about our system at various abstraction levels. However, the end user is like that man on the street, all they see are the external characteristics. Because of this, the operator interface is among the most important parts of the system.

SEMI established the E95 standard as general guidelines for screen layout of tool control software. CIMControlFramework (CCF) provides a standards conforming shell into which various screens may be added to create a complete operator interface. This allows the tool manufacturer to focus on the unique needs of their tool and have no worry about meeting the standard.

There are several general steps to create an operator interface using CCF:

1. Decide on the technology. In the Windows desktop software world, there are two primary ways of developing a user interface: WinForms and Windows Presentation Foundation (WPF). CCF has historically supported the WinForms environment providing many fully functional WinForms screens. It has also supported WPF, but only provided a single example WPF screen. Cimetrix is in the process of updating WPF support and adding multiple fully functional WPF screens out of the box. Either environment may be used based on what the tool manufacturer’s developers deem appropriate.

2. Establish the requirements. The purpose of the operator interface is for the tool to provide the operator with information about what it’s currently doing and for the operator to tell the tool what to do. Determining the correct way to do this can be one of the hardest parts of designing a user interface. This step is where the best level of abstraction is established. The user should have sufficient information to understand what’s happening without being overwhelmed by too much data. The user should also have enough control to do what needs to be done without having to worry about too many details. The analysis for this step is often done by multi-disciplinary teams using analog methods like whiteboards and pen and paper. Creating avatars for different types of users and then writing stories about what those users will want to do is a good way to help flesh out what’s needed by the operator interface.

3. Evaluate pre-built screens against the requirements. Once the target is established, the screens provided by CCF can be examined for fitness. How well do they fit the target? Some screens may be close enough to the requirements to be used as is. Other screens may be close but require some tweaks to meet the specific needs. Finally, some screens may need to be built from components provided by CCF to satisfy the unique specifications of a particular tool.

4. Assemble the screens into an application. Once a list of needed screens is created, the final step is to put everything together. This is generally the most time consuming part of building an operator interface. This phase is when any custom screens are built or modifications made to existing screens. Finally, all the screens, both custom and pre-built, are added to the framework provided by CCF. CCF has a number of labs to help understand how the various user interface components work together to provide a cohesive whole.

CCF provides the structure, pre-built screens and tools to assist in creating custom ones to give your tool a beautiful skin.

To learn more about CCF, visit the CIMControlFramework page on our website!