6 Replies Latest reply on Nov 6, 2014 12:18 PM by robert_burrough

    Introducing the HKP Exchange

    joe_krolla

      Greetings all,

      Over the course of the last weeks and months we have received a quite number of use cases and request forms for HKP encrypt and decrypt licenses.

      Thank you for the effort, filling out the form and helping us to understand, how you use HKP today.  The completion of the form is not only a requirement to get temporary licenses.

      The data is also essential for us to understand, where we can assist you with scripting examples and where we have more engineering work to do before HKP is completely retired.

       

      However, we are on track with our efforts, retiring HKP at the end of the 7.9 release cycle as planned, probably within the next 12-18 months:

       

      Development efforts are underway in different areas, whether it is new exchange formats, expansion of Automation, or more diagnostics within our layout tools.

      We work with our Open Door partners to get their interfaces off the HKP data types, whether they are going to use Automation, ODB++ or other standards that we will be providing.

      Our own solutions, such as LP Wizard and the translators are on a trajectory for HKP replacement and do not need encryption any more.

       

      What are the next steps to assist you to migrate away from HKP?

      This weekend we will be launching the HKP Exchange as part of this community.

       

      The HKP Exchange is a platform for

      -          sample scripts

      -          alternative solutions

      -          white papers

      -          tutorials

      -          other useful information that we or you consider as useful to share.

      It is intended to complement the discussions within the community.

       

      HKP Exchange is designed to be a true exchange. Contributors in the HKP Exchange are

      -          Customers

      -          BSD team members

      -          Customer support

      -          AEs and consultants

       

      The HKP Exchange comes with a number of examples. Thanks especially to Al Layson and Nadia Ahmad from CSD, who provided a lot of examples to get started with.

       

      We invite you to participate in the HKP Exchange, not just as user of existing content.

      -          Check out the examples

      -          Post your HKP examples and code snippets that you feel may be useful for others (try to add some documentation and a use case description)

      -          Ask in the community or via ASCII_answers@mentor.com for additional examples of code snippets that can perform a specific function.

       

      Our objective is to get as many examples out there as possible, allowing you faster to switch to Automation.

      Thanks

       

      Joe

        • 1. Re: Introducing the HKP Exchange
          chris.smith

          I would like to see mentor invest more time and resources in providing specific examples of automation.

          Perhaps even have users vote a specific function or task and document the breakdown w/ code samples and a webinar.

           

          The lack of input and examples even on this dedicated section is very limited. Honestly most users have learned

          more from the AATK vs. anything here. What about API support for more advanced features that we see in Smart utilites?

           

          Few Questions/Comments:

          1. What should we expect from support in the realm of customer user automation w/ the expedition API?
            1. It seems that the general response is "we don't support customer based scripts"

          2. How are automation defects and SRs ranked against other typical physical PCB defects?
            1. What timeframes should we expect to have resolutions to SRs/DRs for automation?
            2. I fear that essentially they could essentially be at the absolute bottom of the marketing barrel.

          3. Are there any future plans on providing a common neutral format vs. ascii or odb.?

           

          One of the justifications of closing ascii I have heard was because of some users who damaged designs with inputs etc?
          I am sure that it is potentially as dangerous or more with improperly coded API scripting.

           

          Why is the entire customer base punished for the results/actions of a few customers? 
          The customer base also realizes this is also a method to close doors to other 3rd party tools.  I can understand the marketing approach
          and the attempt to retain your base but this also creates conditions where you are limiting the ability to have complimenting tools.

           

           

          Ascii Works >Doesn't require mentor resources> Customer is on their own.
          API 85% works >Customer have to spend time, money and resources and loose productivity >Customer is on their own

           

           

          Sorry for the long post but for us it comes down to this:
          If something is broke or missing in the API we have to wait or pray it is available on future releases. With Ascii we can overcome any defect/issue faster and in much less time than learning "available" API hooks on our own.

          • 2. Re: Introducing the HKP Exchange
            joe_krolla

            Chris,

            the posting may be long, but spot on.

            Engineering is standing by to assist our customers, with specific examples. But what examples are the ones you (and other customers) are looking for?

            Instead of just walking off and create some examples, we want to focus on the right ones.

            As mentioned above in my original posting, we are seeking customer input on which specific code examples would help most.

            Please submit your input here for engineering review.

             

            The removal of HKP is not a collective punishment for an unintended usage. Its more a need coming along with the binary database. Who would dare to extract data from an enterprise database in ASCII, manipulate it and load it back into - lets say Oracle - hoping that all repationships remain intact.

            We will continue to expand the Automation capabilities over the next releases, allowing to eliminate all previous use cases of HKP, which cannot be addressed today with Automation or with other exchange formats are promoted by Mentor Graphics, specifically EDIF and ODB++.

            As you see, you were spot on with these exchange formats as well. They are key parts of our replacement strategy as well.

            • 3. Re: Introducing the HKP Exchange
              phil.lindberg

              Joe -

               

                I have an HKP concern I haven't seen addressed elsewhere within MGC Communities, which is specifically related to integrating ECAD and PLM environments.

               

                Our site is developing an ECAD/PLM integration between EE7.9.1 and PTC's Windchill PLM 9.1.

               

                The PTC-supplied toolset is called Workgroup Manager for ECAD. Workgroup Manager for ECAD makes use of HKP for the PCB aspects of the interface, so we're seeing the effects of the encryption in our development work.

               

                MGC and PTC are working together to develop a better approach to ECAD/PLM integration - but production-worthy results from this effort won't be available until well after PTC's upcoming Windchill 10 release.

               

                The schedule estimates I've seen indicate that there's likely to be a one year gap between the end of MGC's support for HKP and the arrival of a next-generation solution. I'm working with MGC on alternate solutions, but am discovering that all have limitations and remaining challenges before they're ready for my users.

               

                Can Automation efforts help address ECAD/PLM issues?  Are you aware of solutions in this area that would be available in the timeframe I'd still have to support a Windchill 9.1 implementation?

               

                 I realize that there are many issues underlying ECAD/PLM integration concerns that go well beyond HKP - but it turns out that HKP happens to be one of the roadblocks I'm seeing today.

               

              Phil

              • 4. Re: Introducing the HKP Exchange
                chris.smith

                Phil,

                 

                We are also at the point of upgrading our Pro/E Intranlink to Windchill 9.1 and I would like to talk to you @ its capabilities w/EE9.2 and PLM.

                Essentially we could be at the same point as you in 2012.

                 

                Thanks

                 

                Chris Smith

                chris.smith@ni.com

                • 5. Re: Introducing the HKP Exchange
                  robert_burrough

                  All,

                   

                  I am actively working on providing alternative samples and solutions for HKP use cases.  As I work through these, I will be posting the samples to the community.  My intent is to add the actual script (when applicable) to the Documents section of the 'Automation and Scripting' community and also update this thread with a description and link as these items are added to serve as a quick reference.  If you have any questions about these or other HKP alternative solutions, feel free to ask.

                   

                  Thanks,

                  Robbie