During the past two years since CP-TA’s inception, we have encountered questions about the need and effectiveness of identifying and testing to interoperability requirements for ATCA, AMC and microTCA.  The typical response is “What value add does CP-TA bring to the PICMG specifications?  Why isn’t PICMG compliance sufficient?”  As a short answer, I highly recommend reading our white paper “Reducing Product Integration Time With CP-TA Tested Building Blocks.”

For a more complete answer, I will begin with the fact that the PICMG specifications were written to encompass as many market segments as possible, including industries such as telecommunications, industrial, military, aeronautical, medical, and others.  This is perfectly acceptable and in fact, optimal, in a specification so that its usefulness and applicability lasts longer than one or two generations in the technology lifecycle.  However, this has the unintended consequences of having too many “optional” requirements.  The mandatory requirements are denoted with the word “shall” in the requirements while the optional requirements are denoted with “should” and “may”.  What happens is that each company that builds an ATCA product, for example, will choose the optional requirements that they believe need to be implemented to make their product successful.  This can, and has, led to ATCA products that do not work together.

To help alleviate the problem, PICMG began coordinating plugfests called Alpha Interoperability Workshops (AIW) shortly after the ratification of the ATCA specification. (Though I believe the early AIWs were intended to help foster a burgeoning ATCA ecosystem to show prospective customers that ATCA products were real and available, and then later shifted focus to solving interoperability problems.)  The AIWs have had great success in solving many interoperability issues.  But integrating ATCA components from different suppliers is still very challenging and this is where CP-TA comes in. 

CP-TA has focused on one market segment – the telecom sector.  We’ve also chosen to concentrate on the three most troublesome functional domains – thermal, manageability, and data transport.  We identified the interoperability issues and the corresponding ATCA requirements needed to overcome those issues.  The requirements have been captured and published in the Interoperability Compliance Document (ICD).  In the process of creating the ICD, input was taken from many of the CP-TA member companies and from the ATCA profile published by the SCOPE Alliance.  We also identified the optional requirements in the ATCA specification that are required to prevent the interoperability issues from being a problem during integration.  You’ll sometimes hear a member refer to this as promoting a requirement: taking a “should” or “may” requirement and making it a “shall” requirement.

These requirements represent the industry’s consensus of what is needed to create an ATCA platform that is “relatively” easy to integrate.  CP-TA’s role has been to facilitate the industry consensus and provide a mechanism to formalize the criteria to achieve interoperability. In the white paper mentioned above, we demonstrate that components tested with CP-TA tools and guidance can significantly reduce integration time. We are proud of our progress so far and look forward to continuing the important work of delivering interoperability to the ecosystem.