Industry News, Trends and Technology, and Standards Updates

The Cimetrix Connectivity Group of PDF Solutions is happy to announce that Cimetrix CIMControlFramework^TM (CCF) version 6.0 is now available for download.

CCF is a software development kit (SDK) that enables users to design and implement a high-quality equipment control solution using provided components for supervisory control, material handling, operator interface, platform and process control, and automation requirements. CCF is built on the reliable Cimetrix connectivity products which provide GEM/GEM300/EDA interface functionality.

We have previously done a series of blog posts on the functionality of CCF. The same great functionality users have come to expect with CCF is still available, but in a cleaner, slicker, easier to use package.

Reorganized directory structure

In versions before CCF 6.0, core CCF packages (packages provided by CCF) were contained in the same directory as sample code and runtime files. This made it more difficult for CCF users to understand what code was required to be customized and what code was basic to CCF. (Note: you can still customize the basic CCF functionality, but it is not required.) In this release, we modified the directory structure to identify more clearly what is core CCF and what is sample or custom code. This is closer to the structure followed by CCF applications. The following diagram shows the new structure:

In addition to clarifying CCF components, the new structure allows us to easily develop samples for additional equipment types. New samples will be added in future versions of CCF.

New WPF framework

Since CCF started providing a Windows Presentation Foundation (WPF) framework, we have received feedback on WPF features user would like added to the framework. Also, our engineers have continued to improve their WPF expertise, which has led to other improvements. CCF 6.0 includes the requested changes and best practice improvements in the new WPF framework. Some of these changes include:

• Simplified hierarchy which makes it easier to understand which objects to inherit from.

• Centralized style elements to allow users to change the look and feel (skin) of the operator interface to meet their needs.
• Enhanced controls library that provides common controls for use in creating equipment control.
• Increased E95 compliance, available with a configurable control panel.
• Accelerated screen creation is possible with the change in hierarchy organization and the enhanced control library.
• Richer set of native WPF screens. In earlier versions, CCF had several native WPF screens, but also had many screens created with WinForms and hosted in WPF. CCF 6.0 has all native WPF screens in the WPF sample operator interface. These screens can be reused, customized, or replaced. (Note: WinForms screens are also still available in CCF 6.0.)

The following image shows the main screen of the WPF operator interface for the CCF atmospheric equipment sample application. Most of the controls on the screen are available for use and customization by CCF developers.

Updated samples

CCF has contained fully functional atmospheric and vacuum sample applications for many years. Over the years, we have improved the functionality for scheduling, simulation, and device interface interaction. However, the samples had always remained the same. With CCF 6.0, the atmospheric and vacuum sample applications were updated to take advantage of the other changes that have been made in CCF. These changes to the samples make them more useful in illustrating the proper use of CCF and providing a better starting point for creating custom applications.

Spring cleaning

CCF was originally released the summer of 2011 making it 10 years-old. Over the years, CCF has had several methods, objects and devices become obsolete. They were not removed from the product for backward compatibility reasons, but they were marked as obsolete. Because CCF 6.0 is a major release, we took the opportunity to do some spring cleaning and remove the obsolete items. CCF is now cleaner and tighter, and using it is much clearer.

Training material and upgrade guide

All the PowerPoint slides, lab documents, and corresponding solutions used for training developers on CCF have been updated for CCF 6.0. We have already successfully used the new training materials with a few customers to help them get started with their equipment control application development.

As part of CCF 6.0, we provide a CCF 5.10 to CCF 6.0 Upgrade Guide that contains detailed instructions on how to migrate applications created using previous versions of CCF to CCF 6.0.

Conclusion

We have been looking forward to the CCF 6.0 release for a long time and are excited for developers to get started using it. We are confident existing users will like the changes and that new users will have a good springboard in getting started with their equipment control application needs. We look forward to working with you and hearing from you.

Hi folks! We in the CCF (CIMControlFramework) Services Team love training/consulting on CCF implementations and building custom software for our customers. We’re especially thrilled when we can help our customers ship new equipment and subsequently hear that the equipment successfully ran thousands millions of cycles without issues.

Recently, we enjoyed helping one of our customers build a tool that processes non-wafer substrates. The tool control system included some typical components such as Rorze Hardware Drivers, Light Tower drivers, and a Load Port E84 IO Control, but had some more unique capabilities as well. In this posting we will explore some of the challenges posed and advantages realized from these special capabilities. Before we dive in, please allow me to give a shout out to John Last, our Senior Software Engineer who designed and built most of these capabilities.

Process Module Operation Screen

Rather than simply logging data points, our customer wanted a visual representation of temperature over time (minutes). We displayed the categorized variables and their values in tables as well, but the graph updating in real time made it much easier for the operator to visualize the patterns and identify risk events and their sources. The graphing feature needed to be active whether or not the process module operation screen was being displayed. Moreover, It had to handle 3 different step types (Ramp, Dwell and Cool).

Calculating the Y-Axis range for this display presented an additional interesting challenge. The minimum and maximum values were determined by searching all recipe steps and selecting the lowest and highest value setpoints, then subtracting a fixed number from the lowest to get the Y-Axis minimum value and adding a fixed number to the highest value to get the Y-Axis maximum value. The figure below shows how the expected process data should look compared to the observed process data. This allows the operator to see what the equipment is expected to do compared with its actual behavior.

Partial FOUP grouping to create a single batch

Our customer required the capability to group multiple partial FOUPs into a single batch. This is especially useful in scenarios where partially filled FOUPs would be used—say, in R&D environments. In other words, we needed to support scenarios where the number of FOUPs needed for processing a batch exceeded the number of load ports. This required us to create Control Jobs with a MtrlOutSpec containing a valid SourceMap with an empty DestinationMap. We relied on SEMI E94’s concept of “Late Announcement of Output FOUP” to specify the input FOUP but not the output FOUP. This allows the scheduler to say, “We know the substrate will go to a different slot, but we won’t tell you which slot until later.”

E90 substrate reading in the Panel solution

As with most tools, each of the substrates has an ID, and this ID must be read and reported to the host. In this case, our host had to verify that the expected ID matched the actual ID. On a successful match, the equipment would then continue the job. If it failed, however, the host would be notified and decide whether to proceed or change something. Capabilities like these maximize throughput and mitigate risks to equipment safety side and production scrap.

Different Panel Types

This machine was required to deal with panels having multiple thicknesses and possible warpage. Therefore we needed to provide a method for an operator, the recipe, and the host to specify the panel type to be processed. None of the variations of panel types were known ahead of time, so we needed methods that handled additional panel types without having to make code changes after the equipment was deployed in production.

The tool also required different substrate mapping parameters for each panel type. Because panel type was specified in the process program referenced in the Process Job, the panel type was not known when the FOUP arrived at the load port. To handle this situation, we customized a standard factory automation SECS II message to communicate the panel type from the host to the tool on arrival of the FOUP.

Conclusion

This equipment was built on an extremely aggressive timeline by a very small team. I was particularly impressed by the team’s ability to grasp the end customer’s requests and creatively explore alternative ways to solve the never-before-seen challenges. In summary: no drama; a few delays; even fewer verbal altercations; just a little frustration; only a little scope creep; and most important, a satisfied factory customer. We all cheered when our customer shipped the tool in 2020.

To find out more about CIMControlFramework and our CCF Services team, or to contact us for a demo, click the button below.

Welcome to the first posting in the Cimetrix CIMControlFramework (CCF) Services blog series! While Cimetrix has been providing professional services for many years, in order to better serve the growing demand from many new equipment maker customers worldwide that have purchased our CCF product, Cimetrix earlier this year formed a new CCF Services group, reporting directly to the CEO. Being a senior developer at Cimetrix for the past 15 years in a variety of positions, I was delighted when asked to lead this group. We have an outstanding team of software engineers highly experienced in factory automation, equipment control software and SEMI standards. We are dedicated to ensuring our customers’ success by providing training, consulting, and developing custom solutions for our CCF customers. We love learning about the myriad ways that companies can integrate CCF with their equipment to meet the material handling and factory automation requirements of their factory customers. Our goal for these articles is to share some of the lessons learned and other implementation insights to help you efficiently build manufacturing equipment that is sophisticated, robust, and productive. To this end, our first posting will deal with one of the most common requests we get – enjoy!

- Forward by Brent Forsgren, Director of CCF Services

How we helped a customer deliver a GEM-compliant equipment using CCF

The Goal

One of our recent customers wanted to build a new type of LED manufacturing equipment that could be controlled by a Factory Host using the standard GEM Remote Commands: PP_SELECT (Process Program Select), START, STOP, ABORT, PAUSE and RESUME. The equipment could be delivered in a variety of physical configurations, including 1-to-multiple source cassettes for product material, and 1-to-multiple process modules. It also had multiple destination cassettes to be filled according to the post-process analysis results. The initial instance of the equipment had 4 loadports (LPs) and four process modules (PMs).

The functional requirements were clear – that was the good news. Now for the rest of the story… the project schedule and budget constraints were closing in, so we needed to work quickly and efficiently with the customer to get it done. Sound familiar?

The Approach

The Cimetrix CCF Services team always works closely with the software team of the equipment manufacturer. In this case, we started with one week of mutual discovery and in-depth hands-on training. Team members were fully engaged and picked up the CCF capabilities very quickly. This included even some of the more advanced features, such as developing a scheduler that would control the components of the customer’s application. We regularly fine tune training modules to 1) introduce CCF concepts, 2) expose common challenges and potential approaches, and 3) provide realistic implementation practice exercises. As anticipated, the customer was able to use the results of the training exercises in the actual equipment control solution. We also kicked off the project with our work-breakdown exercise to more deeply explore the unique requirements for their specific equipment type.

After an intense first week, everyone on the project team concluded that CCF would in fact be a strong match for their needs. CCF features direct integration with our CIMConnect, CIM300, and CIMPortal connectivity products to provide full GEM, GEM300 and EDA compliance. Because the Cimetrix connectivity products are deployed in every semiconductor 300mm factory in the world, our customers can be assured that they will meet their customer’s factory automation requirements. In this application, the end customer’s LED factory only required GEM.

To address requirements that may go beyond the basic GEM standards, CCF also provides support for custom remote commands, data publication, and alarm management. Finally, CCF supports integrating custom hardware devices using CCF’s base Equipment Classes.

To prove all was working, we chose the Cimetrix EquipmentTest product to develop and execute a set of unit tests that emulate communications with the factory software using GEM messages. This was not intended to be a comprehensive set, but rather just enough to show the equipment passed round-trip system testing. In this context, round trip means showing that the equipment can move material from the incoming cassette to the aligner to the process module and back into the cassette. EquipmentTest also supports editing message settings and parameters on the fly to experiment with different configurations of a round-trip test.

The Challenge: “The Host is unavailable, but we need to validate that the equipment is both GEM compliant and accomplishes the communication flows the end user requires.”

We get this challenge a lot… Our customers almost always develop the host interface and the embedded control software in parallel and integrate them later in the project. This makes sense at one level, but it does introduce a “chicken and egg” problem for testing this kind of GEM interface. In particular, how can our customer provide evidence that the solution will work with the factory host without testing with the actual host system? Our answer: apply our EquipmentTest custom plugin capability to simulate the end user’s host so we can validate all necessary communication between host and equipment.

Our protocol validation product, EquipmentTest, makes it possible to simulate communications between an equipment control implementation and the host. And although it is impractical to implement scenarios for every possible interaction, we can create enough representative scenarios to be confident the “happy path” (i.e., no errors) will work and that the interface will handle a large handful of “sad path” cases as well.

Outcome

We passed all the tests! “Let’s go get some tacos.”

Specifically, we validated that the communications interface supported…

• Standard GEM Remote Commands
• Custom Remote Commands
• Material tracking
• Data publication

In closing, we must emphasize that our customer should take most of the credit here. Nevertheless, we enjoyed observing, consulting, and testing the equipment. It is always gratifying to see the CCF solution fit so seamlessly into the hardware, execute its commands with optimal timing, and not break anything in the process! Truly a successful, joint team effort.

If the situation above resonates with your current challenges and past experiences, give us a call. We look forward to working with your software engineering team to speed your time-to-market and deliver a high-quality solution quickly, allowing your team members to focus on developing value-added functionality for your customers.

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!