การออกแบบเฟิร์มแวร์ในตัว

Embedded Motherboard

Embedded Motherboard

ในฐานะนักพัฒนาฮาร์ดแวร์เรายังคงขยายโซลูชันฝังตัวของเราต่อไปและตอบสนองวัตถุประสงค์ด้านการเขียนโปรแกรมและต้นทุนที่สำคัญของลูกค้า

มากกว่า
Thermal Printer

Thermal Printer

Jarltech มีประสบการณ์ในการพัฒนาเครื่องพิมพ์ความร้อนที่มีความน่าเชื่อถือสูง รวมเครื่องพิมพ์ความร้อนขนาด 2 นิ้วและ 3 นิ้ว

มากกว่า

ผู้พัฒนาและผู้ผลิตออกแบบเฟิร์มแวร์ฝังตัวกว่า 30 ปี | จาร์ลเทค

อยู่ในไต้หวัน Jarltech International Inc.ตั้งแต่ปี 1987 มีการออกแบบเฟิร์มแวร์แบบฝังตัว | ผลิตภัณฑ์อิเล็กทรอนิกส์และการรวมฮาร์ดแวร์เพื่อช่วยเหลือลูกค้าจากแนวคิดไปสู่ผลิตภัณฑ์จริง ผลิตภัณฑ์หลัก ได้แก่ การออกแบบวงจรการพัฒนาอิเล็กทรอนิกส์การประกอบ PCB การออกแบบอุตสาหกรรมการพัฒนาฮาร์ดแวร์การผลิตในปริมาณต่ำ PCB DIP โซลูชัน EMS การผลิตแอสเซมบลีการผลิต PCB และอื่น ๆ

ผลิตภัณฑ์อิเล็กทรอนิกส์ที่กำหนดเองของ Jarltech พร้อมกับการพัฒนาด้านวิศวกรรมเช่นวงจรซอฟต์แวร์การออกแบบตัวเครื่องและตัวอย่างการใช้เครื่องมือและการขึ้นรูปการผลิตทางอุตสาหกรรมการรับรองและบริการด้านการตลาด Idea + Design + Production + Service = Jarltech.

Jarltech นำเสนอระบบ POS และอุปกรณ์ต่อพ่วงคุณภาพสูงให้กับลูกค้าทั้งด้วยความรู้ด้านวิศวกรรมที่แข็งแกร่งและประสบการณ์ 29 ปี Jarltech รับประกันความต้องการของลูกค้าแต่ละราย

การออกแบบเฟิร์มแวร์ในตัว

เสนอการทดสอบระบบเพื่อตรวจสอบว่าผลิตภัณฑ์มีคุณสมบัติเกินกว่าข้อกำหนดที่ระบุไว้

การออกแบบเฟิร์มแวร์ในตัว
การออกแบบเฟิร์มแวร์ในตัว

การออกแบบเฟิร์มแวร์ในตัวซึ่งมีการทดสอบระบบเพื่อตรวจสอบว่าผลิตภัณฑ์มีคุณสมบัติเกินกว่าข้อกำหนดที่ระบุไว้

เราออกแบบเฟิร์มแวร์ในห้าขั้นตอน

ในช่วงไม่กี่ปีที่ผ่านมาเราใช้เวลาส่วนใหญ่ในการให้คำปรึกษาและฝึกอบรมทีมพัฒนาซอฟต์แวร์และได้พัฒนาเฟิร์มแวร์ภายในผลิตภัณฑ์ที่มีอายุการใช้งานยาวนานหรือตระกูลผลิตภัณฑ์ที่ประสบความสำเร็จแล้ว แม้ว่าการเรียนรู้ที่จะสร้างสถาปัตยกรรมเฟิร์มแวร์ที่มั่นคงและการออกแบบซอฟต์แวร์รุ่นเก่าไปพร้อม ๆ กันอาจใช้เวลาทำงานหนักหลายเดือน แต่ขั้นตอนสำคัญห้าขั้นตอนนั้นสามารถระบุได้อย่างง่ายดายซึ่งเราใช้กระบวนการทีละขั้นตอนนี้เพื่อช่วยให้ทีมของเราเริ่มต้นได้อย่างถูกต้อง

ขั้นตอนที่ 1: ระบุข้อกำหนด

ก่อนที่เราจะเริ่มออกแบบระบบฝังตัวหรือเฟิร์มแวร์เราต้องมีข้อกำหนดที่ชัดเจน ข้อกำหนดที่เป็นลายลักษณ์อักษรอย่างถูกต้องกำหนดสิ่งที่เป็นผลิตภัณฑ์ ผลิตภัณฑ์จะทำอะไรให้กับผู้ใช้และโปรดทราบว่าข้อกำหนดที่เป็นลายลักษณ์อักษรอย่างถูกต้องนั้นเงียบเกี่ยวกับวิธีการที่ส่วนนี้เป็นพิเศษของสิ่งที่จะบรรลุโดยรวม

คำแถลงข้อกำหนดแต่ละข้อต้องเป็นอีกสองสิ่งด้วย: ไม่คลุมเครือและทดสอบได้ คำแถลงที่ชัดเจนไม่จำเป็นต้องมีคำอธิบายเพิ่มเติม มีความชัดเจนและรัดกุมที่สุด ความสามารถในการทดสอบเป็นกุญแจสำคัญ หากมีการเขียนข้อกำหนดอย่างถูกต้องชุดของการทดสอบสามารถสร้างขึ้นได้อย่างง่ายดายเพื่อตรวจสอบว่าเป็นไปตามข้อกำหนด ชุดข้อกำหนดที่เหมาะสมคือรายการข้อความที่เป็นลายลักษณ์อักษรซึ่งแต่ละคำมีวลีสำคัญ "the [product] should ... " และไม่มีความชัดเจนเกี่ยวกับวิธีการนำไปใช้ไม่คลุมเครือและทดสอบได้ ดังนั้นสถาปัตยกรรมที่ดีจึงขึ้นอยู่กับข้อกำหนดที่ดี

ขั้นตอนที่ 2: แยกแยะสถาปัตยกรรมออกจากการออกแบบ

ในช่วงหลายปีที่ผ่านมาเราพบว่าวิศวกรจำนวนมาก (เช่นเดียวกับผู้จัดการของพวกเขา) พยายามที่จะแยกองค์ประกอบหรือเลเยอร์ต่างๆของวิศวกรรมเฟิร์มแวร์ สถาปัตยกรรมของระบบเป็นชั้นนอกสุดของ HOW สถาปัตยกรรมอธิบายคุณสมบัติถาวร สถาปัตยกรรมนั้นยากที่จะเปลี่ยนแปลงและต้องได้รับการพิจารณาอย่างรอบคอบเกี่ยวกับการใช้ผลิตภัณฑ์ตามวัตถุประสงค์และได้รับอนุญาต

การออกแบบระบบเป็นชั้นกลางของ HOW สถาปัตยกรรมไม่มีฟังก์ชันหรือชื่อตัวแปร เอกสารการออกแบบเฟิร์มแวร์จะระบุรายละเอียดที่ละเอียดเหล่านี้เช่นชื่อและความรับผิดชอบของงานภายในระบบย่อยหรือไดรเวอร์อุปกรณ์เฉพาะยี่ห้อของ RTOS (หากมีการใช้งาน) และรายละเอียดของอินเทอร์เฟซระหว่างระบบย่อย

การใช้งานเป็นชั้นต่ำสุดของ HOW หากอินเทอร์เฟซถูกกำหนดไว้อย่างเพียงพอในระดับการออกแบบข้างต้นวิศวกรแต่ละคนจะสามารถเริ่มใช้งานชิ้นส่วนต่างๆแบบขนานกันได้ ส่วนที่ยากเหล่านี้มีความสำคัญแตกต่างกันไปบ้างในแต่ละอุตสาหกรรม แต่มุ่งเน้นไปที่ความท้าทายใหญ่ ๆ สามประการที่ต้องแลกมาซึ่งกันและกัน: การบรรลุตามกำหนดเวลาแบบเรียลไทม์การทดสอบและการจัดการความหลากหลาย การแก้ไขปัญหาเหล่านั้นประกอบด้วยสามขั้นตอนสุดท้าย

ขั้นตอนที่ 3: จัดการเวลา

ข้อกำหนดบางประการของผลิตภัณฑ์จะกล่าวถึงระยะเวลาที่ชัดเจน ผลิตภัณฑ์ส่วนใหญ่มีการผสมผสานระหว่างข้อกำหนดที่ไม่ใช่แบบเรียลไทม์ซอฟต์เรียลไทม์และฮาร์ดเรียลไทม์ การกำหนดเวลาที่ไม่ชัดเจนมักเป็นสิ่งที่ท้าทายที่สุดในการกำหนดในลักษณะทดสอบและดำเนินการที่ไม่คลุมเครือ เมื่อมีการระบุกำหนดเวลาขั้นตอนแรกในสถาปัตยกรรมคือการผลักดันข้อกำหนดด้านเวลาให้มากที่สุดเท่าที่จะเป็นไปได้จากซอฟต์แวร์และไปยังฮาร์ดแวร์

การแยกฟังก์ชันการทำงานแบบเรียลไทม์ออกจากซอฟต์แวร์จำนวนมากนั้นมีประโยชน์ด้วยเหตุผลสำคัญสองประการ ประการแรกเนื่องจากช่วยลดความยุ่งยากในการออกแบบและการใช้งานซอฟต์แวร์ที่ไม่ใช่แบบเรียลไทม์ ด้วยข้อกำหนดด้านความตรงเวลาที่กำหนดขึ้นจากซอฟต์แวร์จำนวนมากโค้ดที่เขียนโดยผู้ใช้งานมือใหม่สามารถใช้งานได้โดยไม่ส่งผลกระทบต่อความปลอดภัยของผู้ใช้ ข้อดีประการที่สองของการรักษาฟังก์ชันแบบเรียลไทม์ไว้ด้วยกันคือช่วยลดความยุ่งยากในการวิเคราะห์ที่เกี่ยวข้องกับการพิสูจน์กำหนดเวลาทั้งหมดที่เป็นไปตามกำหนดเสมอ

ขั้นตอนที่ 4: ออกแบบเพื่อทดสอบ

ต้องมีการทดสอบระบบฝังตัวทุกระบบ โดยทั่วไปการทดสอบจะต้องดำเนินการในหลายระดับ ระดับการทดสอบที่พบบ่อยที่สุดคือ
1. การทดสอบระบบตรวจสอบว่าผลิตภัณฑ์โดยรวมตรงตามหรือเกินกว่าข้อกำหนดที่ระบุไว้ โดยทั่วไปการทดสอบระบบได้รับการพัฒนาอย่างดีที่สุดนอกแผนกวิศวกรรมแม้ว่าอาจจะพอดีกับสายรัดทดสอบที่พัฒนาโดยวิศวกรก็ตาม
2. การทดสอบการรวมจะตรวจสอบว่าส่วนย่อยของระบบย่อยที่ระบุในไดอะแกรมสถาปัตยกรรมโต้ตอบตามที่คาดไว้และให้ผลลัพธ์ที่สมเหตุสมผล โดยทั่วไปการทดสอบการบูรณาการจะได้รับการพัฒนาอย่างดีที่สุดโดยกลุ่มทดสอบหรือบุคคลในวิศวกรรมซอฟต์แวร์
3. การทดสอบหน่วยตรวจสอบว่าส่วนประกอบซอฟต์แวร์แต่ละตัวที่ระบุในระดับการออกแบบระดับกลางทำงานได้ตามที่ผู้ใช้คาดหวัง นั่นคือพวกเขาทดสอบในระดับของ API สาธารณะ (Application Programming Interface) ที่คอมโพเนนต์นำเสนอไปยังส่วนประกอบอื่น ๆ โดยทั่วไปการทดสอบหน่วยจะได้รับการพัฒนาอย่างดีที่สุดโดยผู้ที่เขียนโค้ดภายใต้การทดสอบ

การทดสอบระบบทั้งสามแบบนั้นพัฒนาได้ง่ายที่สุดและแน่นอนว่าอาจต้องมีการพัฒนาสายรัดทดสอบสำหรับการทดสอบทางวิศวกรรมและ / หรือการทดสอบการยอมรับจากโรงงาน แต่โดยทั่วไปแล้วยังคงง่ายกว่าการรวมและการทดสอบหน่วยซึ่งต้องการการมองเห็นเพิ่มเติมภายในอุปกรณ์เมื่อทำงาน เพื่อให้การพัฒนาใช้งานและการบำรุงรักษาการรวมและการทดสอบหน่วยเป็นเรื่องง่ายจึงมีประโยชน์ที่จะออกแบบเฟิร์มแวร์ในลักษณะที่เข้ากันได้กับกรอบการทดสอบซอฟต์แวร์ วิธีเดียวที่ดีที่สุดในการทำเช่นนี้คือการออกแบบการโต้ตอบระหว่างส่วนประกอบซอฟต์แวร์ทั้งหมดในระดับที่คุณต้องการทดสอบ

ขั้นตอนที่ 5: วางแผนสำหรับการเปลี่ยนแปลง

การพิจารณาที่สำคัญในช่วงสถาปัตยกรรมเฟิร์มแวร์ของโครงการคือการจัดการความหลากหลายของคุณลักษณะและการปรับแต่งผลิตภัณฑ์ ในการวางแผนสำหรับการเปลี่ยนแปลงคุณต้องเข้าใจประเภทของการเปลี่ยนแปลงที่เกิดขึ้นในผลิตภัณฑ์เฉพาะของคุณก่อน จากนั้นออกแบบเฟิร์มแวร์เพื่อให้การเปลี่ยนแปลงเหล่านั้นทำได้ง่ายที่สุด หากซอฟต์แวร์ได้รับการออกแบบมาอย่างดีความหลากหลายของคุณลักษณะสามารถจัดการได้ผ่านการสร้างซอฟต์แวร์เดียวด้วยสวิตช์พฤติกรรมเวลาคอมไพล์และ / หรือรันไทม์ในเฟิร์มแวร์ ในทำนองเดียวกันสามารถเพิ่มคุณสมบัติใหม่ ๆ ให้กับสถาปัตยกรรมที่ดีได้อย่างง่ายดายโดยไม่ทำลายฟังก์ชันการทำงานของผลิตภัณฑ์ที่มีอยู่


ข่าวประชาสัมพันธ์