Filter
清除
Role
Software
Content Type
Region
4个电子零件分销商的关键认证 4个电子零件分销商的关键认证 1 min Blog 在快速发展的电子行业景观中,零部件分销商面临着越来越大的压力,需要证明他们遵守一系列对确保产品质量、环境责任和操作安全至关重要的认证。这些认证正在影响电子零部件分销的许多方面,从供应链管理到最终用户满意度,有潜力提供一个战略差异化因素,增强分销商的信任和声誉。 本文将探讨领先的电子零部件分销商正在优先考虑的四种认证,包括: AS6081 – 帮助打击供应链中假冒伪劣零部件的泛滥 ANSI/ESD-S20.20-2021 – 保护敏感电子组件免受静电放电的影响 ISO-9001 – 提升质量管理体系 ISO-14001 – 增强对环境管理的承诺 通过将这些认证整合到操作实践中,分销商可以遵守行业标准,同时将自己定位为质量保证和环境管理的领导者。我们将探索促进遵守这些标准的框架、创新和工具,展示分销商如何利用技术满足和超越要求。 AS6081:确保供应链中的真实性 AS6081A标准旨在打击航空航天供应链中的假冒电子零件。该标准在现有的质量认证,如AS9100和AS9120的基础上建立,专门针对检测和避免欺诈零件设定了严格的流程。符合AS6081标准表明分销商致力于维护一个安全可信的供应链,这对于零部件完整性不容妥协的领域至关重要,如航空航天和国防。 技术实施以确保合规:实现AS6081合规的关键是实施一个强大的测试和验证系统。分销商必须采用全面的方法论,包括详细记录测试结果、接受标准和不合格零件的处理。技术在这里发挥着至关重要的作用,使用先进的测试设备,如X射线检查、扫描电子显微镜和先进的化学测试方法来验证零件的真实性。 挑战与最佳实践:实施AS6081具有挑战性,需要持续的警惕和适应。分销商必须保持最新的员工培训,并确保他们的供应链的每一个部分都遵循标准,通过定期的审计和程序更新来减轻与假冒零件相关的风险。 总的来说,AS6081对于希望保护其运营免受假冒风险、确保安全、可靠性和客户信任的电子零件分销商来说至关重要。 阅读文章
确保医疗设备供应链中的可靠采购 确保医疗设备供应链中的可靠采购 1 min Blog 关键复杂性包括医疗设备的多方面复杂性、复杂的组装过程、严格的监管要求、进出口限制、激烈的竞争环境以及对持续改进(CI)系统的需求(图1)。 为了应对这些挑战,组织可以采取行动投资于研发、实施强有力的质量控制措施、建立健壮的监管团队、了解国际贸易法、区分其产品,并持续改进其运营。 通过解决这些因素,医疗设备公司可以提高其供应链的可靠性,从而改善患者结果。随着全球医疗设备市场预计到2028年将达到7540亿美元,赌注很高,行业必须通过可靠的采购和供应来迎接挑战。 图1:医疗设备采购中需解决的复杂性。 复杂性1:医疗设备的多方面世界 医疗设备的多样性与医疗领域本身一样多样,涵盖了广泛的仪器、机器、植入物、体外试剂和软件,设计用于多种目的。医疗设备的多样性在两个主要层面上运作——人类因素的多样性和设备因素的多样性。这种多样性延伸到不同的维度,承认个体差异。 此外,医疗设备通常是机械性质的,并对人体有惰性效果。它们的范围从简单的日常消费品如眼镜和绷带,到复杂的系统如MRI设备和起搏器。所涉及的技术远远超出了药物科学,包括材料科学、生物工程、工程、电子、软件、信息和通信技术等多个领域。 根据世界卫生组织的数据,现有超过10,000种类型的医疗设备。全球医疗设备市场在2017年达到了近4095亿美元,并预计到2028年将达到7538亿美元。 行动1:投资研发。 组织可以投资研发以跟上医疗技术的最新进展。例如,作为全球医疗技术、服务和解决方案的领导者Medtronic,大量投资于R&D以开发创新的医疗设备。 Medtronic在截至2024年1月31日的十二个月内的R&D支出约为27亿美元,相对于收入的百分比约为9%。这些高额的R&D投资在 可穿戴设备、应用程序、手术机器人和 人工智能方面取得了成功。 与Cosmo Pharmaceuticals和NVIDIA合作,Medtronic推出了GI Genius™ AI Access™平台。该平台旨在加速医疗保健领域人工智能的创新。GI Genius™智能内窥镜模块是首个获得FDA批准、辅助AI的结肠镜检查工具,帮助医生检测可能导致结直肠癌的息肉。( https://news.medtronic.com/2023-03-22-Medtronic-to-boost-AI-innovation-with-new-platform-introduction)。 阅读文章
产品生命周期管理(PLM)如何帮助供应链管理? 产品生命周期管理 (PLM) 如何帮助供应链管理? 1 min Blog PLM是一种系统化的方法,用于管理产品从设计和开发到最终退役或处置经历的一系列变化。另一方面,SCM涉及积极管理供应链活动,以最大化客户价值并实现可持续的竞争优势。 PLM软件市场在2023年的估值为470.3亿美元,预计到2030年将达到803亿美元,复合年增长率为6.9%。这是一个现在和未来都非常重要的行业( 产品生命周期管理(PLM)- 全球战略商业报告(researchandmarkets.com)) 在复杂且高度规范的行业中,PLM和SCM的卓越表现是必要的。航空航天和国防工业占PLM总市场份额的最大比例(23%),这是可以预期的。北美是PLM市场的最大区域,2020年占市场的33%。全球PLM市场中的亚太地区预计将以最高速度增长。( PLM行业统计数据 • WorldMetrics) 框架 一个可视化PLM和SCM交互作用的方法是使用PLM的标准阶段(引入、增长、成熟、衰退)并与供应链运营参考(SCOR)模型叠加(图1) SCOR模型是由供应链委员会(SCC)开发并认可的过程参考模型,提供了一种标准化的衡量供应链绩效的方法,以及分析PLM增值点的有用框架。 图1:PLM与SCM SCOR模型的整合 计划 SCM中的计划阶段涉及预测未来需求并创建满足这些需求的战略计划。在PLM中,这涉及到构思,即基于竞争对手分析、市场空白或客户需求等因素定义产品需求。它还涉及预测增长、成熟和衰退阶段将会是什么样子。在SCM中,计划对应于开发一种策略来平衡需求和供应,对供应链网络进行对齐,并计划现在和将来的物流。 在计划阶段,组织定义其供应链战略,分配资源,并设定绩效目标。了解产品可能的潜力(PLM的增长和成熟阶段)是至关重要的,这样目标才现实,供应链设计才适合近期和未来的需求,资源配置才能适时进行。 PLM在计划中发挥了关键作用,确保产品设计与供应链能力相符,并告知组织需要开发或增加哪些能力。 想象一下,一家汽车制造商计划推出一款新的电动汽车(EV)。PLM确保EV的设计考虑到采购可持续材料、高效的制造过程和可回收性。它向供应链通报了采购什么、从哪里采购、需要什么样的制造足迹,以及回收供应链需要适应什么。 来源 供应链管理中的采购涉及识别、评估和采购运营业务所需的商品和服务。在PLM中,采购可以与引入阶段的设计和开发元素相连,此时识别并采购产品开发所需的资源。它也是PLM的增长和成熟阶段需要考虑的因素,因为从供应商那里获得的材料和服务的数量需要能够满足未来的需求,或者在定义的时间点将替代/额外的供应商引入供应链。 阅读文章
使用ATmega328P开始嵌入式系统的DevOps入门 使用ATmega328P开始嵌入式系统的DevOps入门 1 min Blog Electrical Engineers Electrical Engineers Electrical Engineers DevOps和敏捷方法论已经通过强调协作、自动化和持续改进,彻底改变了软件开发。将DevOps原则应用到我的设计和项目中,已经成为改变游戏规则的一步,提高了效率和可靠性。在这篇文章中,我们将介绍如何为一个使用 ATmega328P微控制器的 现有嵌入式系统项目设置持续集成(CI)工作流。通过本文,你将看到这些实践如何简化你的开发过程并交付更高质量的产品。 理解嵌入式系统的DevOps和敏捷 DevOps是一套实践,由软件界推广,它将软件开发(Dev)和IT运维(Ops)融合为一个持续的流程。在软件界,开发软件然后“扔过墙”给运维团队让他们部署给客户曾是常态。DevOps引入了一种方式,不仅拆除了这堵墙,还将整个过程自动化。在硬件界,我们发现产品开发和生产之间有相似之处,不断地将设计“扔过墙”给我们的制造工程团队,以确保一切都为生产做好了准备。 在嵌入式产品设计中,我们仍然需要将软件通过生产,但面临着比以往任何时候都要快的挑战,并且要以尽可能高的质量交付。通过DevOps原则,我们旨在解决其中的一些挑战。 硬件依赖性:嵌入式系统依赖于硬件和这些PCB的特定修订版。如果不简化为自动化和高度可扩展,测试和部署可能会变得复杂。DevOps实践通过使用相同的硬件和软件设置,并将其通过自动化的持续集成(CI)系统,帮助自动化这些过程。 长时间构建:构建嵌入式软件可能难以设置,并导致长时间的构建。CI通过将构建卸载到云端,利用开发者通常无法访问的更强大的实例,自动化并加速了这一过程。 手动测试:在实际硬件上进行测试是必不可少的,但通常是手动的、乏味的和耗时的。通过硬件在环(HIL)测试的自动化提高效率和准确性,并可以卸载到配置有CI系统的自动化测试设备的设置中。 通过应用DevOps原则,我们能够使用敏捷方法论在构建-测试-部署范式中快速迭代,为我们希望发布到生产的每个附加功能。 它是如何工作的 “构建、测试和部署”是你在讨论DevOps时经常会听到的一组常用词汇。在嵌入式系统中,我们做的事情也是一样的,因为我们的部署同样会进入生产环节(然后是最终客户)。在 项目的仓库中,我们使用Gitlab CI来驱动我们的端到端工作流程,以实现嵌入式DevOps。我们使用所谓的“管道”来创建完成特定任务的作业,例如编译软件、在目标上运行测试或将其作为官方包发布。在Gitlab中,管道是一系列按顺序流动的作业集合,如下所示: 图1:在Gitlab中使用的ATmega328P DevOps工作流程示例管道 这里是CI脚本(.gitlab-ci.yml文件)的细节分解,以给你一个如何工作的概念。 Docker:如 容器化构建和运行环境以进行硬件在环测试中所讨论的,这个阶段构建Docker镜像,以创建一个一致的环境来构建、测试和刷新代码。这确保了在不同的机器和架构(例如桌面PC与树莓派)上构建过程的可重现性。 测试:这个阶段运行单元测试,以验证你的代码是否按照你的意图进行操作。自动化测试在修改或重构现有代码时快速且重要。 阅读文章
嵌入式系统架构:当您的产品拥有多个PCB时 嵌入式系统架构:当您的产品拥有多个PCB时 1 min Altium Designer Projects Electrical Engineers Electrical Engineers Electrical Engineers 在当今技术驱动的世界中,嵌入式系统无处不在。无论是联网的剃须刀还是复杂的汽车,嵌入式设备都是我们今天使用的大多数电子设备的核心。由一个或多个微处理器组成,嵌入式系统可以通过将复杂性卸载到软件来简化电子产品。随着嵌入式设备变得更大更复杂,印刷电路板(PCBs)也是如此。这些设备往往会发展成多个板并成为比最初预期更大的组装。 在本文中,我们将探讨由多个PCB组成的嵌入式系统的架构权衡和考虑因素。我们将讨论多PCB系统的好处、设计考虑因素和挑战。 为什么使用多个PCBs? 虽然将设备保持在单个PCB上是理想选择(无论是简单性还是成本),但有时我们必须将设计分成两个甚至更多的PCB,以实现我们的设计目标。我们想要将产品分成多个板的一些原因包括: 模块化:将组装分成多个板意味着如有必要,您只能更换产品的一部分。例如,如果单个PCB失败,可以更换它而不影响整个系统。如果正确执行,这可以减少制造商的成本和时间。 空间优化:通过在多个板上分配组件,设计师可以实现更紧凑、更高效的布局。想象一个非常长、狭窄的单板与几个短的、堆叠的板,由于包装的原因,高度并不重要。 热管理:可以在不同的PCB上分配产生大量热量的组件,以改善热量散发。通过在整个组装中均匀分配热量,您可以大大提高系统的可靠性。 可扩展性:使用多个PCB设计允许增量功能添加,可以通过单个板而不是整个组装来更换。想象一下,升级传感器或相机而不替换整个计算系统。 出于这些(以及更多)原因,我们考虑设计一个由多个PCB组成的组装,但嵌入式固件方面的挑战并非没有复杂性。 针对多PCB组装的嵌入式设计考虑因素 现在我们已经确定了使用多个PCB(在适用的情况下)的理由,理解在架构嵌入式系统时的设计考虑因素很重要。无论是从硬件还是软件的角度来看,当我们把一切都放在单个板上时,我们不倾向于仔细权衡的细微差别。 首先我们应该考虑的是板与板之间的通信问题。每块板如何相互通信?每块板上有什么样的处理能力(如果有的话)?或许其中一块板是大脑,而其他的是传感器?当我们仔细选择传输协议,无论是I2C、SPI、UART、以太网等,我们还必须考虑传输线、信号完整性,最重要的是,通过板与板之间的连接器进行信号传输。对设计师来说,最糟糕的事情(相信我,我经历过)就是设计完整个系统并从制造商那里收到你的PCB,只为了意识到你漏掉了一个或两个时钟信号。我们也倾向于忘记在我们的板与板连接器上保留备用引脚,试图将每个引脚数量最大化。这真的可能最终对我们不利。设计时要考虑到多板项目,如 Altium Designer中的多板组装功能,在PCB之间布线如此多的通信线时这是必须的。 我们还需要考虑如何分配电源,特别是如果我们将用我们的微处理器监控电源总线。我们希望能够访问“大脑”以便它能监控任何灾难性事件,但我们也需要考虑切换电源噪声、重负载的电源分配,以及我们的板与板连接器引脚是否能承受那种电力。 最后,虽然这与嵌入式系统的软件本身不直接相关,但机械设计也扮演着重要角色。按键、触摸屏和其他用户的物理接口仍然连接到微处理器,必须考虑在内。我们能否以这样的方式布线,以便微处理器可以访问它的输入?我们是否考虑了当我们从一块板传递到另一块板时高速数字输出的信号完整性?这些是我们在构建我们的嵌入式设备时必须考虑的事情。 挑战与解决方案 我一次又一次在规模扩大的初创公司(甚至是大公司)中看到的最被低估的挑战之一,就是软件和硬件之间版本控制方案的困扰。管理软件发布与PCB修订版之间的关系已成为一个永无止境的战斗,这经常导致混淆、延迟,甚至产品失败。 例如,在我参与的一个初创公司中,PCB的轻微修改需要重新旋转,因此,需要更新固件(尽管很小)。由于版本控制不善,工程团队在旧版PCB上部署了新固件,导致意外的电源下降和偶尔的烟雾。幸运的是,我们在产品发货前发现了这个问题,但这绝对是连续几天的噩梦。 为了避免这些陷阱,建立一个坚固的版本控制方案并确保硬件和软件团队之间的清晰沟通至关重要。即使是一个简单的版本控制方案,如固件的Git哈希(或语义版本)以及硬件修订版的基本支持查找表,也足以开始。随着时间的推移,更复杂的机制,如在固件中检测硬件修订版(从而检查兼容性),也大大减少了混淆。 阅读文章