การดำเนินการ Battery Passport ไม่ใช่โครงการติด QR Code เท่านั้น สำหรับแบตเตอรี่ที่นำเข้าสู่ตลาดสหภาพยุโรป ผู้ประกอบการที่รับผิดชอบต้องรวมการตัดสินขอบเขต เจ้าของข้อมูล 71 จุด การเชื่อม PLM/MES/QMS/BMS/ERP การแบ่งสิทธิ์ การอัปเดต และหลักฐานตรวจสอบไว้ในระบบปฏิบัติงานเดียว บทความนี้เน้นแบตเตอรี่ EV, LMT และแบตเตอรี่อุตสาหกรรมเกิน 2 kWh จากไทยและอาเซียน แล้วแปลงข้อกำหนดเป็น RFP และเกณฑ์รับมอบ
ข้อสรุปก่อน: กำหนดผู้รับผิดชอบและเส้นทางอัปเดตก่อนรวบรวมข้อมูล 71 จุด
ตั้งแต่วันที่ 18 กุมภาพันธ์ 2027 แบตเตอรี่ EV ทุกลูก แบตเตอรี่สำหรับยานพาหนะขนาดเบา หรือ LMT ทุกลูก และแบตเตอรี่อุตสาหกรรมทุกลูกที่มีความจุมากกว่า 2 kWh ซึ่งวางจำหน่ายหรือเริ่มใช้งานในสหภาพยุโรป ต้องมีบันทึกอิเล็กทรอนิกส์ที่เรียกว่า Battery Passport ผู้ประกอบการที่นำแบตเตอรี่สำเร็จรูปเข้าสู่ตลาดต้องรับรองว่าข้อมูลถูกต้อง ครบถ้วน และเป็นปัจจุบัน แม้มอบหมายงานให้ผู้ให้บริการได้ แต่การซื้อแพลตฟอร์ม DPP ไม่ได้โอนความรับผิดชอบดังกล่าวโดยอัตโนมัติ
โครงการที่นำไปใช้ได้จริงต้องตัดสินใจเจ็ดเรื่องตั้งแต่ต้น
- ยืนยันประเภทแบตเตอรี่ ผู้ประกอบการที่รับผิดชอบ ขอบเขต model และขอบเขตแบตเตอรี่รายลูก
- แปลง 71 จุดข้อมูลเป็นเมทริกซ์ owner/source/frequency/access class/validation
- แยกข้อมูลส่วนกลางระดับ model ออกจากสถานะ เหตุการณ์ และ time series ของรายลูก
- แยกข้อมูลสาธารณะ ผู้มี legitimate interest และหน่วยงาน/คณะกรรมาธิการ
- แยกบทบาท QR, unique identifier, DPP Registry และแหล่งเก็บข้อมูล DPP รายละเอียด
- เมื่อ repurpose หรือ remanufacture ให้สร้าง passport ใหม่และเชื่อมกับ passport เดิมหนึ่งรายการหรือหลายรายการ
- ระบุในสัญญาทั้งฟังก์ชัน หลักฐาน FAT/SAT ความต่อเนื่อง และความรับผิดชอบเมื่อกฎเปลี่ยน
แนวทางของคณะกรรมาธิการยุโรปวันที่ 21 สิงหาคม 2026 จัด 71 จุดข้อมูลเป็น mandatory, optional, conditional หรือยังไม่ต้องกรอก/แสดง ณ เดือนกุมภาพันธ์ 2027 เอกสารระบุด้วยว่าไม่ได้เพิ่มข้อกำหนดทางกฎหมายและไม่ใช่การตีความกฎหมายอย่างเป็นทางการ การตัดสินผลิตภัณฑ์จริงต้องตรวจ Regulation (EU) 2023/1542, delegated/implementing acts ที่ใช้ ณ เวลานั้น มาตรฐาน สัญญา และผู้เชี่ยวชาญ บทความนี้เป็นแนวทางด้านการนำไปใช้และการจัดซื้อ ไม่ใช่คำปรึกษากฎหมาย
เริ่มจากตัดสินขอบเขตการดำเนินการ Battery Passport
อย่าตัดสินว่าทั้งบริษัทอยู่ในขอบเขตเพียงเพราะเกี่ยวข้องกับแบตเตอรี่ ต้องพิจารณาทีละ model จากประเภท ความจุ การใช้งาน เส้นทางเข้าสู่ตลาด EU และบทบาทของผู้ประกอบการแต่ละราย
| แกนตัดสิน | สิ่งที่ต้องยืนยัน | ตัวอย่างหลักฐาน | ผลต่อการออกแบบ |
|---|---|---|---|
| ประเภทแบตเตอรี่ | EV, LMT หรือ industrial | specification, intended use, เอกสาร type | เปลี่ยนจุดข้อมูลที่ใช้ |
| ความจุ | ถ้าเป็น industrial มากกว่า 2 kWh หรือไม่ | rated specification, BOM | ป้องกันสับสนระหว่าง “มากกว่า” กับ “ตั้งแต่” |
| ความสัมพันธ์กับ EU | วางจำหน่ายหรือเริ่มใช้ใน EU หรือไม่ | สัญญาขาย Incoterms ข้อมูล importer | กระทบผู้รับผิดชอบและเวลา |
| แบตเตอรี่สำเร็จรูป | เป็น cell/module หรือ finished battery | โครงสร้างผลิตภัณฑ์ บรรจุภัณฑ์ ฉลาก | แยก supplier ต้นน้ำจากผู้รับผิดชอบสินค้าสำเร็จ |
| ผู้ประกอบการ | ใครนำ finished battery เข้าสู่ตลาด | trade flow สัญญา นิติบุคคล EU | ระบุผู้รับผิดชอบตาม Article 77(4) |
| วงจรชีวิต | original, re-used, repurposed, remanufactured หรืออื่น ๆ | work order ประวัติกรรมสิทธิ์/ขายใหม่ | ตัดสิน passport ใหม่และ lineage |
อย่าสับสน EV, LMT และแบตเตอรี่อุตสาหกรรมเกิน 2 kWh
EV battery ใช้กับรถยนต์ไฟฟ้า ส่วน LMT battery ใช้กับ e-bike, e-moped, e-scooter และยานพาหนะขนาดเบา แบตเตอรี่อุตสาหกรรมอาจรวมอุปกรณ์โรงงาน โทรคมนาคม เกษตร การผลิต/จ่ายพลังงาน ระบบกักเก็บแบบอยู่กับที่ และการใช้งานอื่นตามนิยามในกฎ ต้องอ้างนิยามทางกฎหมาย ไม่ใช่ชื่อทางการค้า และเกณฑ์สำหรับ industrial battery คือ “มากกว่า 2 kWh” ไม่ใช่ “2 kWh ขึ้นไป”
ไล่ตาม trade flow แม้โรงงานไทยไม่ได้ขายเข้า EU โดยตรง
โรงงานไทยอาจส่ง finished battery ให้ EU importer ผลิต OEM ให้ brand owner หรือฝังแบตเตอรี่ในเครื่องจักรที่ขายเข้า EU แต่ละเส้นทางทำให้บทบาทต่างกัน ผู้ขาย cell อาจต้องส่งข้อมูล composition และ due diligence แต่ไม่ได้เป็นผู้รับผิดชอบ passport ของ finished battery เสมอไป ขณะเดียวกันผู้รับผิดชอบปลายทางก็สร้างข้อมูล material composition, carbon footprint, recycled content หรือ due diligence โดยลำพังไม่ได้ แผนผัง trade flow จึงควรมีลูกศรสี่ชนิด: ความรับผิดชอบทางกฎหมาย การส่งข้อมูล การเดินระบบ และการอนุมัติ
ผลลัพธ์ของการตัดสินขอบเขต
ก่อน PoC ให้สร้าง scope register ระบุ model, category, capacity, use, EU market route, ผู้รับผิดชอบที่คาดไว้, จุดข้อมูลที่ใช้, เอกสาร/URL อ้างอิง, ผู้ตรวจ และวันที่ตรวจ เมื่อผลตัดสินเปลี่ยน ต้องมองเห็นผลกระทบต่อ passport, label, contract และ acceptance test

ความรับผิดชอบสำหรับ EU Batteries Regulation 2027
Article 77(4) กำหนดให้ economic operator ที่นำแบตเตอรี่เข้าสู่ตลาดรับรองว่าข้อมูลใน passport ถูกต้อง ครบถ้วน และเป็นปัจจุบัน สามารถมอบอำนาจเป็นลายลักษณ์อักษรให้ operator อื่นดำเนินการแทนได้ แต่คำว่า “ผู้ให้บริการ DPP SaaS ดูแล compliance” ยังไม่ใช่โมเดลความรับผิดชอบที่เพียงพอ ต้องทำ RACI ตามกลุ่มข้อมูล
| บทบาท | ความรับผิดชอบหลัก | ข้อมูลเข้า | การอนุมัติ/หลักฐาน |
|---|---|---|---|
| เจ้าของการนำเข้าสู่ตลาด EU | scope, final approval, registration, continuity | ทุกระบบและ supplier | อนุมัติ publish และ change |
| Engineering / PLM | model, chemistry, rating, BOM | released BOM, specification, change no. | design release, version history |
| Manufacturing / MES | unit ID, lot, process/inspection genealogy | execution, equipment, timestamp | trace chain, rework history |
| Quality / QMS | test, conformity, deviation, CAPA | inspection/audit | conformity decision, signature |
| BMS / connected product | status, cycle, temperature, SOC, event | unit time series/event | timestamp, quality/missing flag |
| ERP / supply chain | economic operator, supplier, sale, shipment | partner, order, shipment | trade flow, shipment hold |
| Sustainability / compliance | footprint, due diligence, recycled content | verification/declaration | period, basis, approval |
| DPP service / IT | ID, API, access, availability, audit | synced source data | log, backup, recovery |
RACI ต้องบอกมากกว่าว่าใครกรอกค่า ต้องระบุผู้ถือหลักฐาน ผู้อนุมัติการเปลี่ยน ผู้ตรวจ expiry และผู้มีสิทธิ์หยุดเผยแพร่หรือหยุดส่งสินค้า บริษัทข้ามชาติอาจมี compliance owner ที่สำนักงานใหญ่ data owner ที่โรงงานไทย และ registration owner ที่ EU importer จึงควรกำหนดเป็น role ขององค์กร ไม่ผูกกับบุคคลเดียว
แปลง 71 จุดข้อมูลเป็นเมทริกซ์ควบคุม 5 ด้าน
หากวัดผลเพียง “กรอกครบ 71 ช่อง” จะได้ตารางที่ไม่รู้ source และ trigger ในการอัปเดต ให้เพิ่มห้าคอลัมน์ควบคุมในแต่ละแถวของ guidance เมทริกซ์ 71 × 5 นี้เป็นแบบจำลองการนำไปใช้ ไม่ใช่แบบฟอร์มที่กฎหมายบังคับ
| คอลัมน์ | คำถามออกแบบ | คำตอบที่อ่อน | นิยามสำหรับรับมอบ |
|---|---|---|---|
| Owner | ใครรับผิดชอบความหมาย/คุณภาพ | ฝ่าย IT | PLM Product Data Owner |
| Source | ระบบ/เอกสารใดเป็นข้อมูลหลัก | Excel | Released PLM BOM vX, QMS report ID |
| Frequency | อะไร trigger การอัปเดต | เมื่อจำเป็น | model release, unit event, daily sync |
| Access class | ใครอ่านได้ | ผู้เกี่ยวข้อง | public / legitimate interest / authority |
| Validation | เงื่อนไขเผยแพร่คืออะไร | ตรวจด้วยตา | type, unit, range, reference, signature, freshness |
รักษา applicability ของ 71 จุด
เก็บสถานะ mandatory, optional, conditional และยังไม่ต้องกรอก/แสดง ณ กุมภาพันธ์ 2027 พร้อม applicability ตาม category และแหล่งกฎหมาย อย่าตีความ optional ว่าลบทิ้งตลอดไป และอย่าตีความเลข 71 ว่าทุกข้อบังคับกับแบตเตอรี่ทุกชนิดในวันเดียวกัน ข้อมูล conditional ต้องมีเงื่อนไขและหลักฐานเพื่อประเมินใหม่เมื่อผลิตภัณฑ์เปลี่ยน
กำหนด data contract ก่อนทำ API
แต่ละ element ต้องมีชื่อ ความหมาย type unit ช่วงที่ยอมรับ การแทน missing value ค่า enumeration ฐานเวลา identifier อ้างอิง version และ confidentiality class คำว่า capacity อย่างเดียวไม่บอกว่า rated หรือ remaining, Ah หรือ kWh, model หรือ unit measurement ส่วน temperature อาจเป็นค่าปัจจุบัน ค่าสถิติรายช่วง ค่าเมื่อเกิด event หรือช่วงทนได้ขณะเก็บ ต้องตรึงความหมายก่อนเชื่อมระบบ
แบ่งการอัปเดตเป็นสามรูปแบบ
- Model update: BOM, chemistry, rating, warranty และ design test revision
- Individual event: ผลิต ส่งมอบ ซ่อม อุบัติเหตุ เปลี่ยนสถานะ และ repurpose
- Time series: cycle, SOC, temperature, state of health ตามรอบหรือ event
ไม่จำเป็นต้อง real-time ทุกข้อมูล แต่ batch ปีละครั้งอาจไม่เพียงพอสำหรับข้อมูลจากการใช้งาน ต้องกำหนด freshness SLA, retry, missing data, late arrival และ correction ตามประเภทข้อมูล
แยก model data ออกจากข้อมูลรายลูกและ time series
Annex XIII แยกข้อมูล battery model กับข้อมูล individual battery การออกแบบจึงควรมี model ID และ unit unique ID เป็นคนละ key
| ชั้นข้อมูล | ตัวอย่าง | แหล่งหลัก | Trigger |
|---|---|---|---|
| Model master | chemistry, composition, rated capacity/voltage, expected life, warranty, dismantling | PLM, QMS, compliance repository | approved design change |
| Unit identity | unique ID, model ID, lot, build time, shipment state | MES, ERP, DPP | build/shipment |
| Unit status | original, re-used, repurposed, remanufactured, waste | service/lifecycle system | controlled transition |
| Usage time series | cycle, SOC, temperature, state of health | BMS, IoT platform | interval/event |
| Negative events | accident, abnormal/safety event | BMS, QMS, service | event/confirmation |
| Evidence | test report, declaration, approval, calculation basis | QMS, document store | approval/expiry |
ไม่จำเป็นต้องคัดลอก raw time series ทุก sample มาที่หน้าจอ passport เสมอ ต้องตรวจ granularity, retention, aggregation, access และ download right ตามกฎที่ใช้ แล้วทำให้ข้อมูลเข้าถึงได้จาก BMS/IoT ที่เป็น source of truth หากเปลี่ยน sensor, clock drift, สัญญาณขาด หรือผูก unit ID ผิด dashboard อาจดูครบแต่ใช้เป็นหลักฐานรายลูกไม่ได้
แบ่งสิทธิ์ public, legitimate interest และ authority
แม้ทุกคนสแกน QR ได้ ก็ไม่ได้หมายความว่าข้อมูลทั้งหมดเป็นสาธารณะ กฎแบ่งข้อมูลอย่างน้อยสามชั้น
| ชั้นสิทธิ์ | ผู้ใช้ทั่วไป | ตัวอย่างข้อมูล | การควบคุม |
|---|---|---|---|
| Public | ผู้บริโภคและธุรกิจทั่วไป | model identification และข้อมูลสาธารณะที่ใช้ | อ่านโดยไม่ login, integrity, availability |
| Legitimate interest | repairer, remanufacturer, second-life operator, recycler และผู้มีสิทธิ์ | composition รายละเอียด, dismantling/safety, unit status/usage | verify องค์กร purpose scope expiry audit |
| Authority / Commission | notified body, market-surveillance authority, Commission | test report และข้อมูลตามกฎ | strong identity, entitlement, evidence retention |
Legitimate interest ไม่ใช่ shared URL
ต้องตรวจองค์กร บทบาท วัตถุประสงค์ unit ที่ขอ ชุดข้อมูล และช่วงเวลา ให้สิทธิ์เท่าที่จำเป็น ยกเลิกเมื่อพนักงานออก สัญญาจบ หรือหมดวัตถุประสงค์ บันทึกการดูและดาวน์โหลด ป้องกัน bulk extraction, forwarded URL และ shared API key บุคคลที่มีสิทธิ์และขอบเขต reuse ต้องตรวจจาก implementing measures ที่มีผล ณ เวลานั้น
คุมทั้ง field และเอกสารหลักฐาน
ซ่อน field ใน UI ไม่พอ หาก PDF, API, CSV export, cache, log หรือ support tool ยังเปิดเผย ต้องใช้ access decision เดียวกันกับ field, document, API, export, cache, backup และ admin support ไม่ใส่ข้อมูลลับใน error message สาธารณะหรือ search index

แยกขอบเขต QR, unique ID, DPP Registry และ DPP data store
ควรถือว่าเป็นสี่ส่วนต่างกัน
- QR carrier: จุดเข้าบนตัวแบตเตอรี่ ต้องควบคุมคุณภาพพิมพ์ ความทน ตำแหน่ง และการเปลี่ยน
- Unique identifier: key ระบุตัวแบตเตอรี่ ต้องมีการออกเลข ป้องกันซ้ำ ยกเลิก พิมพ์ใหม่ และ lineage
- DPP Registry: ดัชนีระดับ EU คณะกรรมาธิการอธิบายว่าเก็บ unique identifiers, registration data และ high-level metadata ไม่ใช่ full DPP ทั้งหมด เว้นแต่ applicable acts กำหนดข้อมูลเพิ่ม
- DPP data store/resolver: บริการข้อมูลรายละเอียดแบบกระจาย ดูแลโดย responsible operator หรือ provider ที่ได้รับอนุญาต และบังคับ access class
เส้นทางอ่านทั่วไปคือ QR → unique ID/resolver → access decision → DPP data store และต้องลงทะเบียน Registry ตามกฎหมายก่อนวางสินค้าในตลาด EU อย่ารอ Registry จนไม่เตรียมข้อมูลภายใน แต่ก็อย่าล็อก API ที่คาดเดาเอง ให้แยก Registry adapter ออกจาก business data เพื่อรองรับการเปลี่ยน interface
แบบจำลองสถาปัตยกรรม 6 ระบบ
บทความนี้ใช้ PLM, MES, QMS, BMS, ERP และ DPP เป็น reference model ไม่ใช่จำนวนระบบตามกฎหมาย PLM ดูแล model/BOM, MES ดูแล unit genealogy, QMS ดูแล test/conformity, BMS ดูแล usage state, ERP ดูแล trade flow และ DPP ดูแล resolution/access/publication องค์กรอาจเพิ่ม IoT platform, MDM, data lake หรือ document system หรือรวม MES กับ QMS
Non-functional requirements ที่ต้องมี
- ส่งข้อมูลแบบ open, machine-readable, structured, searchable และ interoperable
- export และ exit plan ที่ทดสอบแล้วเพื่อลด vendor lock-in
- ความต่อเนื่องเมื่อ responsible operator/provider หยุดดำเนินการใน EU
- data authentication, reliability, integrity, security และ privacy
- time sync, correlation ID, audit log, signature/hash และ version history
- redundancy, backup, recovery test และวิธีทำงานเมื่อ resolver ล่ม
- quality gate สำหรับหลักฐาน supplier หมดอายุ หน่วยผิด และ version ไม่ตรง
เมื่อ repurpose หรือ remanufacture ต้องสร้าง passport ใหม่และ lineage
การเขียนทับ record เดิมทำให้ประวัติ design การใช้งาน และความรับผิดชอบหาย Article 77(7) กำหนดให้แบตเตอรี่ที่ผ่าน preparation for re-use, preparation for repurposing, repurposing หรือ remanufacturing มี passport ใหม่ เชื่อมกับ passport เดิมหนึ่งรายการหรือหลายรายการ และความรับผิดชอบย้ายไปยัง operator ที่นำแบตเตอรี่ใหม่นั้นเข้าสู่ตลาดหรือเริ่มใช้งาน
Lineage อาจเป็นหลายต่อหลาย
stationary pack สำหรับ second life อาจรวม module จาก original pack หลายชุด หรือ pack เดิมหนึ่งชุดอาจแยกเป็นหลายผลิตภัณฑ์ field previous_id เดียวจึงไม่พอ ต้องมี relation table ระบุ relation type, source passport, target passport, operator, timestamp, component ที่ใส่/ถอด, test และ approval
ควบคุม state transition
กำหนด transition ที่อนุญาต เช่น original → repurposed → waste → recycled และปฏิเสธการย้อนกลับหรือการลบโดยไม่มีสิทธิ์ ไม่ควรสืบทอด rating, capacity, safety information หรือ warranty แบบอัตโนมัติ ต้อง hold shipment จน responsible operator ใหม่อนุมัติและ passport ใหม่พร้อม

แบบจำลอง PoC 90 วันสำหรับ Battery Passport ที่พร้อมออก RFP
แผน 90 วันนี้เป็นข้อเสนอของ TOMAS TECH ไม่ใช่ระยะเวลาตามกฎหมาย การรับรอง หรือช่วงผ่อนผันก่อนปี 2027 ระยะจริงอาจยาวขึ้นตามจำนวนผลิตภัณฑ์ คุณภาพข้อมูล supplier และการเปลี่ยน acts เป้าหมายคือพิสูจน์ responsibility, data, access และ evidence ในขอบเขตเล็ก แล้วสร้าง production RFP
วันที่ 0–15: ยืนยัน scope และ responsible operator
- เลือก model ตัวแทนหนึ่งรุ่นและ unit ประมาณ 10–50 ลูกเป็นสมมติฐาน
- บันทึกเหตุผลว่าเป็น EV, LMT หรือ industrial >2 kWh
- ทำแผนผัง manufacturer, brand owner, importer, service provider และ EU route
- ให้ legal/compliance ตรวจ version ของ guidance 71 จุดและ acts ที่ใช้
- ใช้แนวทาง EU Digital Product Passport ฉบับทั่วไปสำหรับฐานร่วม โดย PoC นี้เน้น Annex XIII และ BMS ของแบตเตอรี่
วันที่ 16–30: ทำ 71 × 5 matrix และ gap register
- รักษาสถานะ mandatory/optional/conditional/not required ณ Feb 2027 ตาม category
- ใส่ owner, source, frequency, access, validation
- บันทึกค่าปัจจุบัน หลักฐาน gap การแก้ระบบ และ supplier dependency
- เทียบวิธีเป็นเจ้าของข้อมูลกับแนวทางเตรียม DPP สำหรับเหล็กโดยไม่คัดลอกสมมติฐานของวัสดุมาใช้กับแบตเตอรี่
วันที่ 31–50: ทำ identifier และเชื่อม 6 ระบบ
- map model ID, unit unique ID, lot และ passport ID
- ดึงเฉพาะข้อมูลที่จำเป็นจาก PLM/MES/QMS/BMS/ERP
- normalise เข้า DPP store พร้อม source record ID และ version
- ทดสอบ QR สำหรับ ID ถูกต้อง ไม่พบ ซ้ำ และยกเลิก
- ทดสอบ Registry กับ official specification และ test environment ปัจจุบัน ไม่รับเฉพาะ mock
วันที่ 51–70: ทดสอบ access และ lifecycle
- positive/negative test สำหรับ public, legitimate-interest, authority
- ทดสอบ API, CSV, attachment, log, cache และ support tool
- ผูก cycle, temperature, SOC, state of health, negative event กับ unit ที่ถูกต้อง
- สร้าง repurposed passport ใหม่เชื่อม original passport
- inject supplier delay, communication outage, clock drift, duplicate event และ correction
วันที่ 71–90: จบ FAT/SAT และ production RFP
- เชื่อม requirement กับ test ID, expected result, evidence และ owner
- FAT ตรวจ mapping, access, API, audit, backup/recovery, portability
- SAT ตรวจ QR จริง network โรงงาน ข้อมูล BMS/MES จริง operator และ shipment hold
- อนุมัติ unresolved gap, manual control ชั่วคราว, regulatory risk และ cost driver
- ใส่ rollout wave, supplier onboarding, support และ change control ใน RFP
สิ่งที่ต้องเขียนใน Battery Passport RFP
คำว่า “รองรับ EU Batteries Regulation” หรือ “DPP ready” กว้างเกินไป ต้องให้ supplier ตอบวิธี ข้อจำกัด ความรับผิดชอบ หลักฐาน standard/custom version และเงื่อนไขเกิดค่าใช้จ่าย
| หมวด RFP | คำถามบังคับ | หลักฐานส่งมอบ |
|---|---|---|
| Scope | แยก EV/LMT/industrial >2 kWh อย่างไร | scope register, rationale |
| 71 data | coverage ตาม category/condition คืออะไร | 71 × 5 matrix, gap, mapping |
| Identity | ผูก QR, unique ID, model, unit, lot อย่างไร | ID spec, duplicate test |
| Architecture | แยก Registry และ detailed store อย่างไร | data flow, interface, boundary |
| Access | บังคับ public/legitimate/authority อย่างไร | role matrix, negative log |
| Update | อัปเดต model/event/time series อย่างไร | SLA, retry, reconciliation |
| Lifecycle | สร้าง passport ใหม่เมื่อ repurpose อย่างไร | lineage demo, status audit |
| Interoperability | export, migration, schema change อย่างไร | machine-readable export, exit plan |
| Continuity | อยู่ต่อเมื่อ operator/provider หยุดได้อย่างไร | backup, transition, restore test |
| Security | ปกป้อง authenticity/integrity/privacy อย่างไร | threat model, log, incident plan |
| Regulatory change | ใครติดตาม acts/guidance/standards | dated baseline, impact SLA |
| Acceptance | FAT/SAT ผ่านด้วยอะไร | traceability matrix, evidence pack |
สัญญาควรรวม data ownership ข้อจำกัดการใช้ซ้ำของ provider subprocessor ที่ตั้งข้อมูล การแจ้ง outage การแก้ vulnerability end of support การเปลี่ยน specification export และ migration เมื่อยกเลิกสัญญา อย่าอ้างราคาตลาดหรือ ROI ที่ไม่มีฐาน ให้แตก cost driver เป็นจำนวน model/unit ปริมาณ BMS update จำนวน supplier/interface ภาษา availability retention และความถี่ audit
การรับมอบ FAT/SAT: ใช้หลักฐานที่ trace ได้ ไม่ใช่ demo หน้าจอ
| Test ID | การทดสอบ | ผลที่คาด | หลักฐาน |
|---|---|---|---|
| T01 | trace ค่า passport กลับ source | ถึง record, version, approval | mapping export, screen, audit log |
| T02 | field ไม่เข้าเงื่อนไข | เก็บเหตุผล ไม่ใช่ช่องว่าง | rule, input, result |
| T03 | unique ID ซ้ำ | reject และ hold shipment | error, MES/ERP hold log |
| T04 | QR เสีย/พิมพ์ใหม่ | reissue โดย unit เดิมไม่เปลี่ยน | reprint history, old carrier |
| T05 | public ขอข้อมูลจำกัดสิทธิ์ | ไม่คืนข้อมูล restricted | UI/API/export negative log |
| T06 | legitimate interest หมดอายุ | reject และให้ต่ออายุ | entitlement, access log |
| T07 | BMS ขาดการสื่อสาร | แสดง last update/missing ไม่สร้างค่าคาดเดา | timestamp, quality flag, alert |
| T08 | event ซ้ำ/สลับลำดับ | idempotent และ reconcile | correlation ID, reconcile log |
| T09 | repurpose | passport ใหม่ link ต้นทาง | relationship, approval |
| T10 | Registry/store ล่มบางส่วน | ตรวจพบและ reconcile | queue, alert, log |
| T11 | provider export | ย้าย data, relation, evidence ได้ | export/import rehearsal |
| T12 | backup restore | restore แล้ว QR resolve ได้ | restore report, hash comparison |
FAT ตรวจ mapping, logic, security และ interface ในสภาพแวดล้อมควบคุม SAT ตรวจฉลากจริง scanner network โรงงาน BMS/MES operator กะการทำงาน และ shipment control ที่ไซต์ไทย อย่าจบ SAT ด้วย synthetic data อย่างเดียว ให้ผ่าน representative unit แบบ end-to-end การประเมิน conformity และ legal review ยังเป็นอีกกระบวนการหนึ่ง
ความผิดพลาดที่พบบ่อย
ถือว่า QR Code คือผลงานสุดท้าย
QR เป็นเพียงทางเข้า หากไม่มี identity, access, source, update, availability, Registry registration และ audit ที่เชื่อถือได้ ก็ยังไม่ใช่ passport operation ต้องทดสอบให้ unit จริง model Registry metadata และ detailed store ตรงกัน
กรอก Excel 71 แถวแล้วหยุด
Excel ดีสำหรับ gap แรก แต่ตาม engineering change, manufacturing, BMS event และ supplier evidence ที่หมดอายุได้ยาก หากใช้ manual control ชั่วคราว ต้องมี owner, dual check, expiry และ migration plan
เปิดเผยทุก field
ความโปร่งใสต้องอยู่ร่วมกับความลับทางการค้า ให้ access class อยู่ใน data model ไม่ใช่ซ่อนเฉพาะ UI และควบคุม bulk export, support access, reuse นอกวัตถุประสงค์
คิดว่า DPP Registry คือฐานข้อมูล DPP ทั้งหมด
Registry เป็น shared index เป็นหลัก ส่วน detailed hosting, provider exit, access request, retention และ continuity ยังเป็นหน้าที่ที่ต้องออกแบบ
เขียนทับ passport เดิมหลัง repurpose
ทำให้ lineage หายและอธิบาย design, use, state, test, responsibility เดิมไม่ได้ ต้องเก็บ many-to-many relation และ audit history ที่ลบไม่ได้
ล็อก specification ที่ยังไม่แน่นอน
ตรวจ delegated/implementing acts, standards และ Registry specification ล่าสุดก่อนตัดสิน สัญญาควรกำหนด baseline date, monitoring, impact assessment, estimate, test และ controlled release
ประเด็นสำหรับโรงงานไทยและอาเซียน
โครงการลงทุน BEV และการประกอบแบตเตอรี่ของ Hyundai ที่ BOI ไทยเผยแพร่เป็นตัวอย่างของ supply chain ที่ขยายในภูมิภาค แต่ไม่ได้ตัดสินขอบเขต passport หรือผู้รับผิดชอบ ต้องไล่ EU route ของ finished product แต่ละรายการ
ใน supply chain หลายภาษา ปัญหาหนักมักไม่ใช่การแปลไทย ญี่ปุ่น อังกฤษ หรือเวียดนาม แต่เป็น identity และ data definition ร่วม หน้าจอใช้ภาษาท้องถิ่นได้ โดย API field, unit, code และ timestamp ใช้พจนานุกรมเดียวกัน Supplier onboarding ต้องมี sample payload, validation rule, error return, correction และ evidence expiry ไม่ใช่เพียง CSV template
ถ้า network โรงงานไม่เสถียร ต้องออกแบบ store-and-forward, sequence, retry, deduplication หาก BMS cloud และ MES ใช้เวลาคนละแหล่ง ให้ normalise เป็น UTC พร้อมเก็บ original timestamp/timezone อย่าเหมารวมว่าข้อมูลอยู่ EU แล้วถูกกฎหมายเสมอ หรืออยู่นอก EU แล้วห้ามเสมอ ต้องตรวจ privacy, trade secret, contract และ data transfer กับผู้เชี่ยวชาญ
Checklist ก่อนออก RFP
- [ ] จัดประเภทแต่ละ model เป็น EV, LMT หรือ industrial >2 kWh
- [ ] map candidate responsible economic operator ใน EU trade flow
- [ ] บันทึก version/date ของ guidance และกฎหมายที่ตรวจ
- [ ] รักษา mandatory/optional/conditional/not-required class
- [ ] ใส่ owner/source/frequency/access/validation ครบ 71 แถว
- [ ] นิยาม model ID, unit unique ID, lot, passport relation
- [ ] ระบุ source of truth ใน PLM/MES/QMS/BMS/ERP/DPP
- [ ] แยก public/legitimate/authority ใน UI/API/export/attachment
- [ ] ออกแบบ QR, unique ID, Registry, detailed store เป็นคนละ component
- [ ] แยก Registry adapter และ change control
- [ ] สร้าง passport ใหม่และ original link เมื่อ repurpose/remanufacture ได้
- [ ] คุมเวลา/คุณภาพของ event, temperature, SOC, cycle, state of health
- [ ] ทดสอบ continuity, export, restore เมื่อ operator/provider หยุด
- [ ] เขียน negative FAT/SAT และรูปแบบหลักฐานใน RFP
- [ ] ระบุว่า PoC 90 วันเป็น proposal model ไม่ใช่ระยะตามกฎหมาย
- [ ] มี gate ตรวจ final decision กับกฎหมาย acts มาตรฐาน และผู้เชี่ยวชาญ
สรุป: เปลี่ยน Battery Passport ให้เป็นกระบวนการพร้อมส่งมอบ
แก่นของความพร้อมปี 2027 ไม่ใช่ตาราง 71 แถวหรือรูป QR แต่คือความสามารถของ responsible operator ในการระบุ model/unit รวบรวมข้อมูลที่ควบคุมจากระบบและ supplier แบ่ง access อัปเดตการเปลี่ยน และอธิบายย้อนถึงหลักฐาน เมื่อนำ scope register, 71 × 5 matrix, การเชื่อม 6 ระบบ, ขอบเขต Registry, lifecycle lineage และ FAT/SAT มารวมใน requirements traceability matrix คำถามใน RFP จะเปลี่ยนจาก “รองรับ DPP หรือไม่” เป็น “รับมอบเมื่อหลักฐานชุดนี้ผ่าน”
แม้ยังอยู่ในขั้นกำหนดประเภทแบตเตอรี่และเส้นทาง EU ก็สามารถปรึกษา TOMAS TECH เรื่อง gap assessment 71 จุด แบบจำลอง PoC 90 วัน Battery Passport RFP และ FAT/SAT ได้ ติดต่อผ่านแบบฟอร์ม TOMAS TECHพร้อมข้อมูล category ที่คาด ผู้ที่จะนำสินค้าเข้าสู่ตลาด EU และขอบเขต PLM/MES/QMS/BMS/ERP ปัจจุบัน
คำถามที่พบบ่อย
Battery Passport เริ่มบังคับเมื่อใด?
Article 77(1) กำหนดวันที่ 18 กุมภาพันธ์ 2027 สำหรับ EV battery ทุกลูก LMT battery ทุกลูก และ industrial battery มากกว่า 2 kWh ทุกลูกที่วางตลาดหรือเริ่มใช้งานใน EU ต้องยืนยันผลิตภัณฑ์และบทบาท operator ตามกฎที่มีผลจริง
จุดข้อมูล Battery Passport 71 รายการบังคับทั้งหมดหรือไม่?
ไม่ทั้งหมด Guidance เดือนสิงหาคม 2026 จัดเป็น mandatory, optional, conditional หรือยังไม่ต้องกรอก/แสดง ณ กุมภาพันธ์ 2027 พร้อม applicability และ legal source ต้องอ่านฉบับล่าสุดคู่กับ Regulation เพราะ guidance ไม่ใช่การตีความกฎหมายที่มีอำนาจผูกพัน
QR Code ของ Battery Passport เก็บข้อมูลทั้งหมดหรือไม่?
QR เชื่อมกับ unique identifier และเป็นทางเข้าสู่ passport ไม่ได้หมายความว่ารายละเอียดทั้งหมดฝังอยู่ในภาพ ต้องออกแบบ carrier, identifier, resolver, access, detailed store และ Registry registration แบบ end-to-end
เชื่อม DPP Registry แล้วถือว่าจบหรือไม่?
ไม่จบ คณะกรรมาธิการอธิบาย Registry ว่าเป็น index ของ unique identifier, registration data และ high-level metadata ขณะที่ detailed DPP เป็นระบบกระจาย จึงยังต้องมี source, update, access, continuity และ audit ภายใน
ใครรับผิดชอบความถูกต้องของข้อมูล?
ตาม Article 77(4) economic operator ที่นำแบตเตอรี่เข้าสู่ตลาดต้องรับรองความถูกต้อง ครบถ้วน และเป็นปัจจุบัน สามารถมอบอำนาจเป็นลายลักษณ์อักษรได้ แต่การ outsource data entry หรือซื้อ platform ไม่ได้โอนความรับผิดชอบอัตโนมัติ
แบตเตอรี่ที่ repurpose ใช้ passport เดิมได้หรือไม่?
กฎต้องการ passport ใหม่ที่เชื่อมกับ passport เดิมหนึ่งรายการหรือหลายรายการ ต้องเก็บ purpose, responsible operator, status และ test ใหม่ พร้อมรักษา lineage เดิม
PoC 90 วันรับรอง compliance ได้หรือไม่?
ไม่ได้ 90 วันเป็นแบบจำลองข้อเสนอในบทความ ไม่ใช่ระยะตามกฎหมายหรือคำรับรอง เหมาะสำหรับพิสูจน์ scope ตัวแทนและสร้าง production RFP กับ gap ที่บันทึกไว้ การตัดสิน compliance ต้องตรวจอีกครั้งกับกฎหมายและผู้เชี่ยวชาญ
ผลงานสำคัญที่สุดใน Battery Passport RFP คืออะไร?
Requirements traceability matrix ที่เชื่อม requirement, design, source data, test และ evidence พร้อม 71 × 5 matrix, ID specification, access matrix, data flow, lineage, negative test, export/recovery และ change control
แหล่งอ้างอิง
- Regulation (EU) 2023/1542 — Articles 77–78 และ Annex XIII
- European Commission — Guidance to support preparations for the Digital Batteries Passport (21 August 2026)
- European Commission — Digital Product Passport for Batteries
- European Commission — Digital Product Passport overview
- European Commission — The DPP Registry
- Thailand BOI — Hyundai BEV and battery assembly project