『The Agile Embedded Podcast』のカバーアート

The Agile Embedded Podcast

The Agile Embedded Podcast

著者： Luca Ingianni Jeff Gable
無料で聴く

Learn how to get your embedded device to market faster AND with higher quality. Join Luca Ingianni and Jeff Gable as they discuss how agile methodologies apply to embedded systems development, with a particular focus on safety-critical industries such as medical devices.2021-2025 Jeff Gable & Luca Ingianni
エピソード
  • Factory Firmware Flashing with Pete Staples

    Factory Firmware Flashing with Pete Staples
    2026/06/09

    We talk with Pete Staples, founder of Blue Clover Devices, about the often-overlooked challenge of flashing firmware in production. Pete shares insights from running a contract manufacturing operation in Shenzhen and explains why the handoff from engineering to manufacturing is more like "hucking it over a fence" than a smooth relay race.

    We explore the gap between engineers' assumptions about factory capabilities and the dusty reality of production floors. Pete discusses security challenges, the complexity of modern microcontroller programming, and how Blue Clover's Production Line Tool addresses the middle ground between expensive custom automation and ad-hoc bench setups. We also touch on provisioning, calibration workflows, and why the engineer who designs the product must also define how it's tested.

    Key Topics
    • [02:30] The reality of factory firmware flashing - dusty PCs, hot glue, and cables everywhere
    • [06:15] Security challenges: managing sensitive firmware and the "glass room" solution
    • [09:45] The gap between engineer assumptions and factory reality - no, they don't have better equipment than you
    • [14:20] In-circuit testing and bed-of-nails fixtures explained
    • [22:30] The Production Line Tool: standardizing hardware and software across engineering and factory
    • [28:00] Recording what matters: firmware versions, hardware serial numbers, and test results per device
    • [31:45] Provisioning and security: webhooks, cloud databases, and managing secrets in production
    • [38:20] The Test Agent: a companion device for running third-party software and complex programming workflows
    • [43:00] Who should write the test plan? Why engineers must define "good enough" before production
    Notable Quotes

    "Engineers assume that the factories are a lot more sophisticated than they really are. In reality, it's a lot more like just hucking it over a fence and just hoping there's somebody there waiting." — Pete Staples

    "They show you their pick-and-place machine and 10-zone reflow oven, and you're like, 'wow, these guys are tipped off.' And then rarely do they say, 'oh, and here's where we do firmware flashing.' It's normally another floor of the building, dimly lit, dusty old PCs." — Pete Staples

    "The engineer responsible for the product has to not only engineer the product, but how it's tested. They can't just say, 'here's a bunch of design files, build it and let's see what happens.'" — Pete Staples

    Resources Mentioned
    • Blue Clover Devices - Pete's company specializing in factory firmware flashing solutions
    • Embedded World (Nuremberg) - Annual trade show in March where Blue Clover exhibits
    • Embedded World North America (Anaheim) - North American version of Embedded World, September 22nd
    • Kinetic (San Francisco) - Hardware-focused event put on by Hardware FYI

    You can find Jeff at https://jeffgable.com.
    You can find Luca at https://luca.engineer.

    Want to join the agile Embedded Slack? Click here

    Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/
    Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/
    続きを読む 一部表示
    51 分
  • Requirements Engineering, part 2: A Practical Process for Safety-Critical Development

    Requirements Engineering, part 2: A Practical Process for Safety-Critical Development
    2026/05/27
    Requirements Engineering Part 2: A Practical Process for Safety-Critical Development

    In this second part of our requirements engineering series, Jeff walks us through his preferred process for developing safety-critical products, particularly medical devices. We explore the crucial distinction between prototyping and design-controlled development, discussing when to start formal requirements work and how to keep your first version minimal yet complete.

    Jeff emphasizes the importance of deeply fleshing out requirements before implementation—including error handling, which often comprises 70% of a product. We discuss tracer bullets as a development strategy, the value of writing test cases alongside requirements, and why tracking requirements completion gives you honest project status. Luca and Jeff also debate the finer points of MVPs versus prototypes, and Jeff announces his upcoming requirements management tool for medical device startups.

    Key Topics
    • [00:00] Introduction and listener feedback on Part 1
    • [02:30] The prototyping phase: answering 'can we build it?' and 'should we build it?' before design controls
    • [06:00] Luca vs. Jeff: The great MVP and prototype debate
    • [12:00] Starting the V-model: minimal but deeply fleshed-out requirements for V1
    • [18:00] Error handling is 70% of your product—don't skip it in requirements
    • [22:00] When to write test cases: early, alongside requirements
    • [26:00] War story: the SATCOM system that needed a satellite slot in five years
    • [32:00] Project management: tracking requirements completion for honest status updates
    • [38:00] Tracer bullets: vertical slices through all layers, not horizontal completion
    • [45:00] Jeff's upcoming requirements and test management tool for medical device startups
    Notable Quotes

    "Error handling is 70% of your product, if not more. If you only do the 30% of the requirements for the happy path, you're fooling yourself." — Jeff

    "If you don't get this right at the outset, it will haunt you through the entirety of your product development process." — Luca

    "Paper is the best place to figure it out. Actually think through the requirements rigorously before you start building." — Jeff

    Resources Mentioned
    • Agile Embedded Slack Channel - Community discussion space for embedded development topics
    • Matt Pocock's YouTube Channel - AI for serious engineers, discusses tracer bullets and AI-assisted development
    • The Pragmatic Programmer - Classic software development book, source of the tracer bullet concept
    • The Art of Unix Programming by Eric S. Raymond - Referenced for the chapter 'Don't just do something. Stand there.'
    • Embedded.fm Episode 440: Condemned to Being Perfect - Crossover episode with Elecia White and Christopher White, where bootloaders and update strategies came up
    • Jeff's Requirements Management Tool - Upcoming requirements, risk, and test management tool for medical device startups

    You can find Jeff at https://jeffgable.com.
    You can find Luca at https://luca.engineer.

    Want to join the agile Embedded Slack? Click here

    Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/
    Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/
    続きを読む 一部表示
    50 分
  • Fuzzing and Dynamic Analysis for High-Integrity Software with Paul Butcher

    Fuzzing and Dynamic Analysis for High-Integrity Software with Paul Butcher
    2026/05/13
    Fuzzing and Dynamic Analysis for High-Integrity Software with Paul Butcher We sit down with Paul Butcher, Unit Director of Dynamic Analysis at AdaCore, to explore verification techniques beyond basic compliance in safety-critical software. Paul shares his experience from Eurofighter to automated trains, explaining how dynamic analysis—from unit testing to coverage analysis to fuzzing—helps find bugs that traditional testing misses. The conversation dives deep into fuzzing: how it works, why it's so effective at finding corner-case bugs (even in well-tested systems), and the challenges of applying it to embedded systems with timing constraints. Paul introduces an intriguing approach that combines static analysis with targeted fuzzing to automatically triage false positives and generate reproducers. We also touch on formal verification, the role of LLMs in verification workflows, and why the simplest software is often the safest. Whether you're working in aerospace, medical devices, or any safety-critical domain, this episode offers practical insights into building more robust systems. Key Topics [02:30] Paul's background in high-integrity embedded systems: Eurofighter, rail, drones, and AdaCore's dynamic analysis tools[05:00] Dynamic vs. static analysis: executing code to observe real behavior across different environments[08:15] How fuzzing works: mutation engines, anomaly detection, and finding bugs through negative testing[14:20] Challenges of fuzzing timing and concurrency bugs in embedded systems[17:45] Real-world success: fuzzing the NH90 avionics via the MIL bus uncovered numerous bugs[22:30] Safety standards (DO-178C, SIL levels) and objective-based approaches vs. checkbox compliance[28:00] Determining 'enough' fuzzing: coverage, input space complexity, and building certification arguments[32:15] Combining static analysis with targeted fuzzing to automatically triage false positives and generate reproducers[38:45] Symbolic execution and theorem provers: breaking through complex branch conditions in fuzzing campaigns[42:00] Shift-left philosophy: building verifiable software from the start with testing and analysis tools[47:30] Formal verification in practice: London Underground's Victoria line uses SPARK-proven emergency braking[51:00] LLMs in verification: cautious adoption for report analysis, but determinism remains critical for core tools[54:30] High Integrity Software Conference (HISC) in Birmingham, October 2026 Notable Quotes "Software testing is typically about, is it functionally correct? Fuzzing is like a negative testing technique. It's the inverse of that. It fires random inputs into your system with the intent of finding anomalies." — Paul Butcher "Every time I speak to someone who's tried fuzzing, even if it's a system that's considered high integrity with a high level of assurance, they always find something. It's really good at eking out those weird corner case scenarios." — Paul Butcher "With testing you would like to prove the absence of bugs, but unfortunately you can't. So you have to settle for a very distant second place of proving the presence of bugs." — Luca Ingianni Resources Mentioned Paul's paper on fuzzing in safety-critical contexts - Detailed discussion of how to argue 'enough' fuzzing for certificationHigh Integrity Software Conference (HISC) - Annual conference in Birmingham, UK (October 2026) covering high-integrity software across industriesAdaCore Dynamic Analysis Tools - Coverage, fuzzing, and unit testing solutions for high-integrity softwareSPARK formal verification - Formal proof technology used in London Underground's Victoria line emergency brakingAFL++ - Successor to the discontinued AFL (American Fuzzy Lop): Fuzzing technology mentioned as capable of quickly finding the Heartbleed bug You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/
    続きを読む 一部表示
    49 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません