Agile Hardware – Aber wie?

Mario Blunk, Blunk ElectronicDr. Tobias Kästner, Method Park Engineering

FED-Konferenz in Bamberg27. September 2018

Doc. Vers. 2018-09-03

Entwicklung, Erprobung, Fertigung von elektronischen Baugruppen

Kleinserien (1..100)

Steuerung des Entwicklungs- und Fertigungsprozesses von der Idee

bis zum Produkt (agile Hardwareentwicklung)

Beratung & Training

3

Method Park is specialist for innovative software and systems engineering.

• 160 Employees• Founded 2001• Erlangen, Stuttgart,

Munich, Detroit, Miami

Ein klassisches Projekt

Ein klassisches Projekt

Dauer der Projektphase Gesamtdauer

Lastenheft 1 Monat 1 Monat

Entwicklung und Fertigung Null-Serie 6 Monate 7 Monate

SW-Integration und erstes erfolgreiches Ende-Zu-Ende Szenario

6 Monate 13 Monate

● Bereits nach 3 Monaten erste Change Requests – für Null-Serie aber bereits zu spät

● Folgerevisionen behoben nicht alle Fehler, verursachten aber neue

● Erfahrenes Team (2 HW-Entwickler, 2 FW-Entwickler, 1 Tester)● Sehr gute Bedingungen (Resourcen, Kommunikation)

Stromlaufplan/SchaltplanBoardlayout/PCBHardware

Firmware

Software

CMOS-Sensor

LEDs

EchtzeitregelkreiseHardware Abstraction Layer

Low-Level Treiberansteuerung

Application Runtime

Microcontroller

Application

Motoren

Ort der Wertschöpfung inhärent durch

Trial & Error getrieben

Systemarchitektur

... dauert es lange

doppelte Genauigkeit, DC- undSchrittmotor, …, 16 Reserve-Pins,

Diskret statt analog, mehr Parts,mehr Netze, ...

höhererHW-Entwicklungsaufwand

Neue HW nur1x pro Jahr !

Just in Case ..

Weil es lange dauert

The developer‘s dilemma

Individuals and interactions over processes and tools

Working [product] over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

[www.agilemanifesto.org (2001)]

That is, while there is value in the items on the right,we value the items on the left more.

That is, while there is value in the items on the right,we value the items on the left more.

The Age of Agile

Source: https://www.versionone.com/agile-101/agile-software-development-benefits/

Vis

ibili

ty

Val

ue

Res

pons

iven

ess

& A

dapt

abili

ty

Ris

k R

educ

tion

Agile

Traditional

Agile

Traditional

Agile

TraditionalAgile

Traditional

time time

The Age of Agile

What Scrum (Sutherland, Schwaber ´95) is :

Project management framework Iterative, incremental development Cycle: Try - Inspect - Adapt

Focus on:

Flexibility Adaptability Productivity

12 + 2 principles12 + 2 principles

practicespractices

4 Manifesto statements5 values

4 Manifesto statements5 values

The Agile Way: Scrum

2-4 Wochen

24h

Backlog Item

Backlog Item

Backlog Item

Backlog Item

Product backlog

Gewinnen neuer und verbessern bestehender Anforderungen durch Interaktion mit Produktinkrement

ProductIncrement

Sprint backlog

Backlog Item

Ready for Transfer

Daily Scrum

Sprint Planning

SprintReview

SprintPrio

ritä

t

The Agile Way: Scrum

Iterationen für Nacharbeit

Konzept / Anforderungen

Block-Diagramm

Schaltplan

PCB Layout

Fertigung

Test / Verifikation

Prozess der HW-Entwicklung

Working PCBA

Umso dramatischerje kleiner die Fläche:

A1<A0

Umso dramatischerje kleiner die Fläche:

A1<A0

Design # Parts # Nets # Pins

Very Complex >1000 >1000 >2000

Complex 750 544 2250

Moderate 315 383 1162

Simple 121 101 350

VerySimple

<100 <70 <200

The Cost of Complexity

Mediumcomplexity

Lowcomplexity

Lowcomplexity

Lowcomplexity

Highcomplexity

• Meist völlig konträr zum klassischen Vorgehen• Kohärenz des Schaltplans nicht mehr automatisch

garantiert• Management zusätzlicher Variationspunkte• Board-to-Board Verbindgungen

• Avoid: All-In-One PCBA - äquivalent zu „Gott-Klasse“ im objekorientiertem SW-Entwurf

• Try: Single Responsibility Principle - mehrere & kleinere PCBAs

• Stabile Features bleiben stabil• Volatile Features können schneller adaptiert werden

Agile Hardware

Core

Shield

MCU/Memory

Feature

Motor Control

Debug/Programming Interface

Feature

Analog Front End

Feature

LED Control

Development Rig

Modularisierung durch definiertes Regelwerk

• Funktionale Dekomposition, z.B. Peripherie vs programmierbare Bausteine

• Standardisierung, z.B. Powerrails

• Guidelines, z.B. Präferenz für digitale Buskommunikation

Agile Hardware – Design Approach

Rig Design – Block Diagram

Power Supply

Debug Circuitry

Heizer-Driver Motor-Driver

MCU / CPU / Storage

Debug CircuitryDebug Circuitry

Debug Circuitry

Konventionen für Schnittstellen

Teile & herrsche !

SHIELD

Debug Circuitry

Rig Design - Development

Nicht schön -

aber schnell !

Bis ca. 25%Zeitgewinn !

Rig Design – Layout w/ Autorouter

Rig Design – Test & Feedback

Rig Design – From Rig to Product

Core + Feature 1 + Feature 2 + Feature 3 => Product

Unter welchen Bedingungen ist obige Reduktion als M2M-Transformation formalisierbar ?

Automation

• Interface zur Firmware/Software• Legt bereits Bill of Materials fest• Muss unter obiger Abbildung invariant sein

(modulo nicht länger benötigter Parts/Netze)

Schaltplan und NetzlisteSchaltplan und Netzliste

Rig Design – From Rig to Product

• Neues Layout ohne “Entwicklungsballast”

• Optimiert für Größe, #Lagen, Formfaktor, etc.

• Neues Layout ohne “Entwicklungsballast”

• Optimiert für Größe, #Lagen, Formfaktor, etc.

Klassische vs. agile Entwicklung

Wann anzuwenden ?

unscharfe Anforderungen

häufig wechselnde Anforderungen

Dokumentation und Verwaltung ufert aus (Lasten/Pflichenhefte)

kurze Entwicklungszeiten (Sprint 2 bis 4 Wochen) gefordert

Vorteile:

Projekt läßt sich besser steuern gegenüber Wasserfallmodell

Rückmeldung vom Kunden innerhalb eines Sprints

weniger „Überraschungen“ bei Auslieferung des Produktes

für SW/FW-Entwicklung bleiben Ports von MCU, FPGA, CPLD …

konstant|

Agile HardwareEin Beispiel

Mario Blunk, Blunk Electronic

Dr. Tobias Kästner, Method Park Engineering

FED-Konferenz in Bamberg27. September 2018

Vorgehensmodell

1. Design neuer Rig-PCBAs ➔ Neue Features (ein Feature pro Modul)➔ Modifikation bestehender Module

2. Herstellung der Rig-PCBAs

Entwicklung (Sprint für Sprint): n

Schaltplan PCB-Layout

PCB-Fertigung

Bauteilbeschaffung

Bestückung

Test/Inbetriebnahme

Testgenerierung

Dokumentation

Vorgehensmodell

1.Schaltplan reduzieren auf Produkt

2.Layout für Produkt erstellen

Ableitung des Produktlayouts aus Rig-Design (nach N Sprints):

Agile Hardware - Tools

- CAE- Werkzeuge müssen automatisierbar sein (skriptbar):

- Löschen von Schaltplanseiten, Bauteilen und Netzen- Feststellung Verstöße gegen Konventionen (ERC/DRC in Datei in Klartext)- Erzeugung von Materiallisten, CAM-Daten- Designdaten in Klartext, ASCII, XML (nicht binär !)- Generierung Dokumentation (Sphinx)- Testgenerierung- Versionskontrolle mit Git siehe http://www.blunk-electronic.de/pdf/git_einfuehrung.pdf

- erprobt mit Autodesk-EAGLE- CERN-KiCad noch in Evaluationsphase

- XILINX-ISE/Vivado (für Logiksynthese)- Blunk electronic Stock-Manager http://www.blunk-electronic.de/products/sw/stock_manager/doc/Stock_Manager_de.pdf

- Blunk electronic Boundary Scan Test System M-1 siehe http://www.blunk-electronic.de/de/produkte.html

Agile Hardware - Tools

Kriterien zur Auswahl eine CAE-Systems

Es sollten diese Fähigkeiten oder Funktionen vorhanden sein:

1. Versionskontrolle mit externen Werkzeugen wie Git. Die Projektdaten müssen, was Änderungen betrifft bis zum Zeitpunkt x zurückverfolgbar sein (Stichwort ISO-Zertifizierungen). Manche Systeme haben eingebaute Versionierfunktionen, die aber nachaußen kaum zugänglich sind. Versionskontrolle mit externen Werkzeugen ist nur möglich, wenn die Datenstruktur des Designsin Klartext (ASCII oder XML) vorliegt (siehe http://www.blunk-electronic.de/pdf/git_einfuehrung.pdf).

2. Designdaten müssen mit externen Werkzeugen, im einfachsten Falle mit einem Texteditor, einsehbar oder änderbar sein.Speichert das CAE-System Designs in kryptischen Binärdateien, taugt es für agile Hardware-Entwicklung nicht !

3. Skriptbarkeit: Eine CAD/CAE-Software, die ausschließlich per Mausklicks zu bedienen ist, macht die Arbeit nicht effizienter (auch wenn der Preis das verspricht). Kritische Routinejobs, wie Instanzierung, Indexierung, Designchecks, BOM-Generierung,ERC, CAM-Datengenerierung müssen automatisierbar sein, indem das Programm per Skript oder Kommandozeile angestoßen wird (z.B. in nächtlichen Build-Prozessen).

4. Projekte müssen modular bearbeitbar sein, solange die Prototypenphase besteht. Das finale Design entsteht durch Fusion der Module. Siehe dazu http://www.blunk-electronic.de/pdf/agile_HW_development_vortrag_de.pdf undhttp://www.blunk-electronic.de/pdf/agile_HW_development_SQ-Magazin-44.pdf. Das Konzept der agilen HW-Entwicklung ist relativneu, wurde aber von uns erfolgreich mit EAGLE in einer medizinischen Anwendung erprobt. Auch hier ist Automatisierung per Skripteelementar.

5. Lizenzmodell. Es greift die Methode der Mietsoftware um sich. Das heißt, solange Sie regelmäßig eine Gebühr entrichten,funktioniert das System, und Sie haben Zugang zu Ihren Designdaten. Dies bindet Sie auf Gedeih und Verderb an den Hersteller des Systems. Davon halten wir überhaupt nichts.

Rufen Sie uns doch einfach an ! Wir beraten gern. Tel: +49 361 6022 5184

Block Diagram

System bestehend aus 4 separaten Modulen

● Design für Core kann aus letztem Projekt übernommen werden● Entwickelt wird Shield, LED Driver und Keyboard● Zu beachten:

● Korrekte Aufteilung des Schaltplans● Einhaltung von Namenskonventionen für Netze und Bauteile

Structure of Schematics

Feature Block

Routing

Debug/D

evelopment

Structure of Schematics

Core

Shield

LED Driver Keyboard

Feature Block

Routing

Debug/D

evelopment

Core – Product PageCore-Modul mit MCU (vereinfacht)

Core – Development PageCore-Modul Versorgung und Steckverbinder zum Shield

Core - Layout

Shield – Core Development PageSteckverbinder zum Core-Modul – aus Shield Template

Shield – LED Development Page

Steckverbinder zum LED-Treiber-Modul und on-board Debug-LED

Shield – Keyboard Development Page

Steckverbinder zum Keyboard-Modul und on-board Debug-LED

Shield – Routing Page

Routing via „Netchanger“ oder „Net-Ties“Netze zwischen Modulen und Core werden verknüpft

Shield - Layout

LED Drv Module – Product Pageprodukt-relevante Schaltungsbestandteile:● „Treiberbaustein“● Anschluss für LED

LED Drv Module – Development Page

Steckverbinder zum Shield – identisch zur entsprechenden Shieldseite

LED Drv Module – Development Page

Steckverbinder für Stromversorgung im Rig

LED Drv Module – Layout

Rig Reduction - Method

Core

Shield

LED Driver Keyboard

1. Merge & Elimination: Combine Schematics into one Schematic & eliminate Debug Pages

LED Driver Keyboard

Rig Reduction - Method

Core

Shield

LED Driver Keyboard

2. Reduction & New Layout: Rename net names from module to core using Routing Page

1. Merge & Elimination: Combine Schematics into one Schematic & eliminate Debug Pages

Rig Reduction - Merge

Schaltpläne der Submodule vereinen (merge)

Rig Reduction - Eliminate

Rig Reduction – Reduce Net Names

Von Module zum Core

vorher:

nachher:

Rig Reduction – Final Schematic

● Schematic reflects structure of rig

● Structure of Rig reflects system model● Good for system validation● FMEAs etc.

● No „spill-over“ or „misplaced parts“

● Same applies for documentation● generated from module

documentation

Rig Reduction – Product Layout

Rig Design - Conventions

Lesbarkeit

Übersicht

zeitsparende Bearbeitung

Wiederverwendung von Schaltungsteilen

Modularisierung / agile HW

Rig Design - Conventions

- Netznamen, Prefixe, ... - Belegung Steckverbinder- LED Helligkeiten- Kennzeichnung Schaltplanseiten- ISO Datumsformat YYYY-MM-DD- Lagenverwendung (Layout)

Rig Design - Conventions

PWR_VREG_IN, PWR_VREG_OUT, PWR_VREG_ADJ

CPU_JTAG_TCK, CPU_JTAG_TMS

KBD_IN, KBD_OUT

LED_DRV_IN, LED_DRV_ON_OFF

CPU_GPIO_1, CPU_GPIO_2

Beispiele :

Rig Design – Net Names

MODULENAME_FUNCTION_COUNT

MODULENAME_BLOCKNAME_FUNCTION_COUNT

Template:Template:

P3V3, GND, AGND, ...

Template:

Rig-globale Netze:

- Texte (auch in Zwischenlagen) helfen Entwicklung und Fertigung

- Zählweise beachten (laut IPC von oben/TOP nach unten/BOTTOM) !

HW Design – Best Practices

Vereinfachung im Layout (netzname N$1701)

verbesserte Lesbarkeit

Vorbereitung zur Modularisierung

Anwendung der Kommandozeile (Skripte)

Vermeidung von Sonderzeichen (µ, ö, ...)

Design-Checks mit externen Werkzeugen

HW Design – Best Practices

Benennung von Bauteilen und Netzen

ANT ANTENNAB BUZZERBAT BATTERYC CAPACITORCA CAPACITOR_ADJUSTABLED DIODEDPH DIODE_PHOTODI DIACDIS DISPLAYF FUSEHS HEATSINKIC INTEGRATED_CIRCUITJ JUMPERJD JUMPER (for development)K RELAYKP KEYPADL INDUCTORLA INDUCTOR_ADJUSTABLELS LOUDSPEAKERLED LIGHT_EMMITTING_DIODELDA LIGHT_EMMITTING_DIODE_ARRAYM MOTORMIC MICROPHONE

N NETCHANGEROC OPTOCOUPLERQ QUARTZR RESISTORRA RESISTOR_ADJUSTABLERN RESISTOR_NETWORKRP POTENTIOMETERRPH RESISTOR_PHOTOS SWITCHT TRANSISTORTP TRANSISTOR_PHOTOTF TRANSFORMERTPT TESTPOINTTH THYRISTORTHP THYRISTOR_PHOTOTR TRIACTUB TUBEX CONNECTORXD CONNECTOR

Beispiele IC1, T1, R1, TP1, RN1

HW Design – Best Practices

m MILLIOHMR OHMk KILOOHMM MEGAOHMG GIGAOHM

p PICOFARADn NANOFARADu MICROFARADm MILLIFARADF FARAD

n NANOHENRYu MICROHENRYm MILLIHENRYH HENRY

V VOLTm MILLIAMPEREA AMPERE

k KILOHERTZM MEGAHERTZG GIGAHERTZ

Beispiele 4k7, 4n7, 2A5, 3V3

Die Bauteilart wie Widerstand, IC, LED … ergibt sich aus Schaltplansymbol und Name:

HW Design – Best Practices

Agile Hardware - Automation

● Electrical Rule Check● PDF-Export● BOM / Verfügbarkeit● Linting● Metriken

Schaltplan

● Design Rule Check● PDF-Export● MCAD-Export● Metriken

Layout

● Gerber / Drill Data● Release Package● Dokumentation

CAM

Danke für Ihre Aufmerksamkeit !

Inhaber: Dipl.-Ing. Mario Blunk

Buchfinkenweg 3

99097 Erfurt / Germany

Gegründet: August 2009Tel. +49 (0) 361 6022 5184

Email: info@blunk-electronic.de

Web: www.blunk-electronic.de

Inhaber: Dipl.-Ing. Mario Blunk

Buchfinkenweg 3

99097 Erfurt / Germany

Gegründet: August 2009Tel. +49 (0) 361 6022 5184

Email: info@blunk-electronic.de

Web: www.blunk-electronic.de