Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PremDay #2 - Factory Data

Avatar for PremDay PremDay
April 11, 2025

PremDay #2 - Factory Data

Asier Roa Mendiguchia from Proton shares his experience around the assembly data shared between vendors and customers, including serials, test type, and error rates during integration before the hardware arrives

Avatar for PremDay

PremDay

April 11, 2025
Tweet

More Decks by PremDay

Other Decks in Technology

Transcript

  1. CLICK TO EDIT MASTER TITLE STYLE OBJECTIVE Deliver working hardware

    ready to provision with minimal validation on arrival
  2. BACKGROUND  Damage on transit will always exist  This

    talk is not going to address logistical issues like  Vibrations  Broken packaging  Customs  Security issues while on transit 3
  3. BACKGROUND  We want to partner with hardware manufacturers to

    work together on validation  Factory staff shortages and training of newcomers  New product introductions  Product configuration unknown to the site 5
  4. BACKGROUND  Vendor: “OK, but where in the manufacturing line?”

     Answer:  We believe that we can bring value during L10 or server integration  i.e. working server able to boot 7
  5. BACKGROUND  Vendor: “Sure thanks but we already do this

    ??”  Answer: You are right!  Some quotes include PN-s that represent test settings  We know that part of the assembly fee includes some test time (6hr/12h/24h?)  Many of us report an assembly tech spec through sales team 10
  6. BACKGROUND  Vendor: “Sure thanks but we already do this

    ??”  Answer: You are right!  Some quotes include PN-s that represent test settings  We know that part of the assembly fee includes some test time (6hr/12h/24h?)  Many of us report an assembly tech spec through sales team  .... but for our engineers it is very hard to follow through and understand what it means or what happened 11
  7. PROPOSAL: WIN / WIN  Faster and more efficient hardware

    supply  Fixing issues at source 13
  8. PROPOSAL: WIN / WIN  Faster and more efficient hardware

    supply  Fixing issues at source:  next to your warehouse + qualified personnel to execute  No logistics involved during repair (less RMAs)  Better inventory management for the factory  Less overheads: less need to dispatch engineers to customers  Safer DCs: isolate production environments 14
  9. IDEAS & PROPOSALS  1 - Test Coverage:  We

    can provide workloads similar to our own production  We can help direct testing on features that are immediate to us 17
  10. IDEAS & PROPOSALS  1 - Test Coverage:  We

    can provide workloads similar to our own production  We can help direct testing on features that are immediate to us  Example:  i/o workload on drive similar to production  With a particular interaction with the drive firmware 18
  11. IDEAS & PROPOSALS  2 - Test Environment:  Vendor:

    “Yes! we validated distributions X and kernel Y, Z” 19
  12. IDEAS & PROPOSALS  2 - Test Environment:  Vendor:

    “Yes! we validated distributions X and kernel Y, Z”  Answer: You are right! But maybe our production teams can help to set the focus on a particular release and hardware combination  Faster kernel patching  Faster hardware resolution 20
  13. IDEAS & PROPOSALS  3 - Assembly & Configuration Tests

     Examples:  Mainboard jumpers or cabling  Validate the power settings by reading information from BMC/BIOS 22
  14. IDEAS & PROPOSALS  3 - Assembly & Configuration Tests

     Examples:  Mainboard jumpers or cabling  Validate the power settings by reading information from BMC/BIOS  Making sure that the flag has been set and no repairs have reverted the status 23
  15. IDEAS & PROPOSALS  4 - Tracking other physical repairs

     Shopfloor system tracking human intervention is useful to identify changes on other components 24
  16. IDEAS & PROPOSALS  4 - Tracking other physical repairs

     Shopfloor system tracking human intervention is useful to identify changes on other components  Example: A mainboard has had more repairs than usual, and has been assembled many times before shipping. Was there a problem on the assembly line? Are all the tests passing again? 25
  17. IMPLEMENTATION IDEAS  We want to suggest 2 changes: 

    How to report assembly test data from factory  How to help the factory setup our test execution environment 28
  18. REPORTING DATA  A way for the factory to report

    assembly results prior to shipping 29
  19. REPORTING DATA  A way for the factory to report

    assembly results prior to shipping  BIOS/BMC settings dump  Test results  Manufacturing Yields 30
  20. REPORTING DATA: TECHNICAL DETAILS  API endpoint  Query by

    serial number  Or leverage cloud (like object storage)  Encrypted, firewalled and only accessible to customers 31
  21. TEST EXECUTION ENVIRONMENTS  Lets define a standard to let

    customer run tests in the factory  Using open source where we can  Time Limited  Packaged by customer as per agreed before hand  Using kernel releases that simulate our production  Have a job format to automatically validate things  Kernel release, tool version, tests parameters, hardware configuration, timings and store the results 33
  22.  And some constraints too  All tests should complete

    successfully  If one test fails: the machine will require retesting  Test results can be safely queried via API as it progresses so that we can speed up repairs 35 TEST EXECUTION ENVIRONMENTS
  23. SUMMARY  More intimate knowledge of your customers:  know

    what we need prior to building it!  Streamlined procurement:  faster resolution means more sales! 38