aspice软件开发流程中dfmea(aspice软件开发流程)
本篇文章给大家谈谈aspice软件开发流程中dfmea,以及aspice软件开发流程对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
- 1、ASPICE 汽车软件过程改进及能力评定
- 2、如何检测汽车零部件?
- 3、DFMEA与IPD开发流程是什么关系?
- 4、ISO26262 中 ASIL 与 DFMEA 有什么区别
- 5、工作笔记 aspice基础知识
- 6、过程流程图,DFMEA,PFMEA,CP的顺序及关系是怎样的
ASPICE 汽车软件过程改进及能力评定
ASPICE:Automotive Software Process Improvement and Capacity Determination
汽车软件过程改进及能力评定,汽车行业评价软件开发团队的研发能力水平模型
由欧盟多家主要汽车制造商共同制定,2005年发布
CMM:最初基于CMM Capability Maturity Model
ISO:国际标准化组织ISO、国际电工委员会IEC、信息技术委员会JTC1联合制定并发布了国际标准ISO/IEC15504,又称SPICE,包含汽车行业SPICE、医疗设备行业、航天行业
ASPICE:从ISO拆分出来,由德国汽车工业联合会(VDA)的质量管理中心(QMC)运营发展
CMM和SPICE:CMM可以针对项目的某个领域、也可以面向整个项目或组织,可以用于评级,如CMMI3,而SPICE只能用于评价项目中的特定过程域( Process Instance )
3个过程组别:主要生命周期过程、组织生命周期过程、支持生命周期过程
双向可追溯性和一致性
评估、验证准则和复合性
过程评估模型分为“过程实施指标”和“过程能力指标”
1.过程实施指标——只适用于L1
又分为:基本实践(BP 面向活动,一组任务或活动)、工作成果物(WP,面向结果)
2.过程能力指标——适用于L2~L5
又分为:通用实践(GP 面向活动)、通用资源(GR 面向基础设施)
【0级】代表一种混乱的状态。
【1级】代表企业已经能够完成产品研发相关的工作,但缺乏管理,虽然偶尔能够成功,但项目中存在大量不确定的因素,对项目缺乏掌控能力,无法确保一定能够按时交付高质量的产品
【2级】代表企业不仅能够完成产品研发相关工作还能有提前制定严谨和周全的工作计划,并能有效根据计划实施项目监控和管理,各项目能够有序进行
【3级】代表不仅各项目能够管理得很好,而且能够有效的从历史项目中积累经验和教训,形成公司的知识资产和标准工作流程,用于对今后项目的参考和指导以及公司管理的持续改善
【4级】引入统计学知识和技术,对项目相关各项数据进行统计和分析,并将之运用于未来的项目管理之中,达到对项目结果的预测,并根据预测结果对项目进行实时的调整,确保达成项目目标
【5级】代表企业能够基于商业目标的需要,主动的对过程进行调整,对变革管理有很强的管理能力,能够基于对过程的量化分析设定明确有效的过程改进目标,并能对过程改进结果进行有效的量化监控和分析
主要聚焦在软件,没有包含硬件和机械功能;其他关键部分可以以拆件的形式融合到ASPICE
如何检测汽车零部件?
以动力电池为例介绍一下新能源汽车动力系统部件的测试,欢迎开发测试工程师一起交流、指正:
动力电池系统作为硬件本体和控制系统结合极为紧密的系统,其测试大致可以划分为两大部分:电池包本体(Pack)测试、电池管理系统(BMS)测试,下面分别介绍这两部分的测试情况;
1. 电池包本体(Pack)测试
电池包本体测试一般在DV/PV(设计验证/生产验证)阶段进行,目的是为了验证电池包的设计/生产是否符合设计要求。其中包含温度测试、机械测试、外部环境模拟测试、低压电气测试、电磁兼容测试、电气安全测试、电池性能测试、滥用试验测试等等。因为大伙都比较关心电池安全问题,在这里主要介绍一下电池包滥用试验的测试方法:
1) 针刺测试
模拟电池遭到尖锐物体刺穿时的场景,因为异物刺入有可能导致内部短路,试验要求不起火不爆炸
2) 盐水浸泡
5%盐水长时间浸没测试,电池功能正常
目前新能源汽车电池包防水防尘等级推荐是IP67(即1米深的水浸泡半小时无损坏,上汽、蔚来的电池包都是IP67)。汽车的使用环境恶劣,再怎么做防水防尘保护也不过分(上海有一年暴雨导致车库积水,传统车都淹挂了,而电动车完好无损)。
3) 外部火烧:
590摄氏度火烧持续130秒电池无爆炸、起火、燃烧并且无火苗残留。
4) 跌落:
1m高度自由落体在钢板上电池壳体完整功能正常
5)振动测试
高频振动模拟测试,要求电池包功能正常。做电池包的同事应该知道,这个也很难通过。
2. 电池管理系统(BMS)测试
电池管理系统的测试更多侧重软件测试,一般在软件功能开发过程中进行。
与尚未量产的自动驾驶系统偏向于使用C语言实现软件设计不同,现今成熟的电动汽车控制系统(如整车控制器、电机控制器、电池管理系统)软件都是以模型为基础的软件开发(Model-Based-Design)。MBD开发相比C的优点是能够以图形化的方式表达复杂的逻辑、代码可读性、可移植性、开发调试便利程度都大大增强,同时利用成熟的代码生成工具链,也避免了手工代码容易产生的低级错误。在基于模型的软件开发环节中规定了MIL/SIL/HIL等多项测试:
1) MIL(Model-In-Loops)既模型在环测试,就是验证软件模型是否可以实现软件功能,测试依据是由系统需求分解而来的软件需求。
2) SIL(Software-In-Loops)软件在环测试,对比模型自动生成的C代码和模型本身实现的功能是否一致,使用Simulink自身工具就可以进行Sil测试。
3) PIL(Processer-In-Loops)处理器在环测试,目的是测试自动生成的代码写入控制器后,功能实现上是否与模型有偏差。PIL看似无关紧要,但不做重视也会引起一些不良后果(如调度问题、CPU Load,堆栈溢出等)
4) HIL(Hardware-In-Loops)硬件在环测试,测试控制器完整系统功能,一般会搭建控制器所在系统的测试台架,使用电气元件模拟传感器(如温度)和执行器(如风扇负载)的电气特性,验证完整的系统功能。
这些测试环节的用例来源于系统需求。在汽车软件开发流程中,开发和测试成V字型进行,俗称软件开发V模型,感兴趣的同学可以查看汽车软件开发流程ASPICE。
统开发流程中非常强调测试软件环节的。要知道手机软件出问题最多也就是秒退而已,车辆软件出问题影响的是人命。
当年丰田刹车门事件,美国政府就派了嵌入式软件专家和卡耐基梅隆的计算机教授详细审查了发动机控制系统的软件代码,丰田对全局变量的滥用(上万个)以及软件安全机制的混乱就遭到了巨额处罚。如果丰田重视软件测试工作的话,这件事也许不会发生。
最后再聊下零部件在整车极限环境下的测试情况:整车耐久测试这部分工作一般是整车厂的测试标定工程师负责。整车耐久试验的花销很大,造工程样车(每辆100万左右)、租用测试场地、工程师团队花销,很考验厂家的资金实力,没有强大的资金池根本无法运行起来。但在极寒、高温、高湿度等各种极限环境下的测试进行的越多,越能充分的验证零部件的功能、性能以及耐久表现,越早发现问题,解决修复所耗费的成本越低。
1. 低温耐久测试,主要测试冷起动性能,一般在黑河/牙克石进行。电池包的低温充放电能力、低温保护策略、电池包加热功能在该项测试中都会进行考核。
2. 高温耐久测试,一般在格尔木进行。主要测试电池包在高温下充放电能力、电池包冷却功能和过热保护策略。下图是蔚来在澳大利亚墨尔本进行高温测试,为了整车开发整车厂都是不惜成本。
3. 高温+高湿环境耐久测试,一般在海南进行,海水环境会加速部件腐蚀,零部件的耐久会经受严格考验。(Ps:传统车还有重要的高原测试,主要测试在低气压下发动机的性能表现。电动车一般不需要进行此项测试。)
电池包做的比较好的都会承诺使用寿命内的电池衰减,比如蔚来ES8就承诺10年30万公里电池容量衰减不超过20%,做电池开发的都知道做到这个水平是非常不容易的。敢公开承诺也说明他们的电池包耐久测试做到了非常优秀的水平。
DFMEA与IPD开发流程是什么关系?
DFMEA与IPD开发流程是什么关系?
(1)DFMEA策划在产品计划阶段结束前完成。DFMEA策划的启动,一般要求在产品设计方案定型以后开始,一般建议该活动放在产品计划阶段内完成。该阶段是我们制定各种产品开发计划的关键阶段。这也包括DFMEA的实施计划。
(2)DFMEA的启动一般在计划阶段结束后。计划阶段结束,产品马上进入开发阶段阶段。该阶段是产品设计实现的阶段,也是DFMEA实施的主要时段。
(3)DFMEA的优化措施必须在样机发布之前完成。要保证让DFMEA分析的结论,能成功的导入设计。那就必须做到在设计冻结之前,完成第一次DFMEA分析。这样才能使我们的DFMEA不流于表面。
(4)DFMEA的更新必须在产品正式发布之前,至少完成一次。在产品的验证阶段,我们要做大量的调试、测试工作,很可能会发现一些设计问题。这些问题需要更新到我们上个阶段的DFMEA分析报告。
(5)DFMEA需要在整个产品生命周期被持续更新。企业是否具备这种观念可以说是DFMEA在这个企业是否被成功实施的重要特征之一。只有坚持持续更新我们的DFMEA分析报告,才能做到知识的不断累积,进而用来提高下一个产品设计的质量。
ISO26262 中 ASIL 与 DFMEA 有什么区别
1. 首先,ISO26262的ASIL与DFMEA的打分对象不同
二者具有相同点,都研究失效(failure)。
2. 然后,二者的思维方法是完全不同的(对应于题主所说的“控制方法”)
3. 最后,二者的概念级别是不同的。
DFMEA与FTA可以是同一级别的概念,是分析失效的两种不同思维方法。
而ISO26262是一整套流程,大体上可以分为几大阶段:
概念阶段Concept Phase
系统开发阶段System Design (V型开发)
硬件开发阶段Hardware Design
软件开发阶段Software Design
工作笔记 aspice基础知识
最近给某OEM做了一次Automotive SPICE CL2评估,很多朋友就问我关于Automotive SPICE评估的一些事情。本文算是一个科普吧,给不太了解Automotive SPICE的人介绍一下Automotive SPICE和Automotive SPICE评估的事情。
1. Automotive SPICE
1.1 什么是Automotive SPICE?
Automotive SPICE是一个”过程模型”,适用于”基于软件的车载系统”的”设计开发过程”。过程模型是一个集合,是包含了与设计开发过程相关的优秀实践的集合。既然是一个集合,那就需要按照一定的结构把这些实践组织起来:
方式一:按照实践所属的不同领域进行组织,比如有些实践是和项目管理相关的,有些实践是和软件需求相关的,有些实践是和软件单元测试相关的….,不同的领域被称为“过程”,这就是Automotive SPICE中的“过程纬度”。Automotive SPICE PAM V3.1中包括有32个过程。
方式二:按照做事情的方式进行组织,比如:依靠个人的经验来做,是能力度级别1(CL 1)的实践;按照可管理的方式(活动管理和工作产品管理)来做,是能力度级别2(CL 2)的实践;按照组织的要求来做,是能力度级别3(CL 3)的实践….,这就是Automotive SPICE中的”能力度纬度”。
“能力度”是“过程的能力度”。如果说“某个项目达到了能力度2级”,是不准确的,应该说“某个项目中的某些过程达到了能力度2级”。同样的,如果说某个组织达到了能力度2级,也是不准确的。
下图是常见的体现评估结果的形式,评估范围内的过程,分别达到了什么样的过程能力度。
1.2 怎么用Automotive SPICE?
Automotive SPICE是欧洲车厂在认识到软件质量的重要性之后,制定的一个规范。目的是希望其供应商能按照Automotive SPICE的要求进行产品的设计开发,以提供高质量的产品。
Automotive SPICE中包括有那么多的过程,那么OEM对供应商的具体要求是什么呢?要求供应商需要应用哪些过程,这些过程需要达到几级呢?
一般来说,OEM不会要求供应商去遵守Automotive SPICE的所有过程的,为什么呢?
性价比!
实施Automotive SPICE的成本,评估的成本,最后都是产品成本,OEM是需要买单的。
所以OEM会基于其对软件质量的理解,选择最重要的过程来要求其供应商。
起初的时候,不同的OEM有不同的使用Automotive SPICE的观点,形成气候的,如下图所示:
说明:
HIS是Audi AG, BMW, DaimlerChrysler, Porsche, Volkswagen成立的制定软件开发规则的组织
如上的过程划分,是基于Automotive SPICE PAM V2.4/V2.5
逐渐的,各OEM的要求开始统一,目前逐渐形成了如下两类:
说明:
2016年HIS组织解散了,VDA QMC(Automotive SPICE PAM V2.5及其以后版本的Owner)在2017年Automotive SPICE PAM V3.0发布时,将之前在业界应用非常广泛的HIS Scope,改名定义为VDA Scope
如上的过程划分,是基于Automotive SPICE PAM V3.0/V3.1
各个与汽车软件相关的供应商在应用Automotive SPICE时,往往最终都是为了满足OEM的要求,其应用Automotive SPICE的过程范围及目标级别,遵照其所服务的OEM的要求。
2. Automotive SPICE评估
接下来我们谈一谈Automotive SPICE评估,在谈Automotive SPICE评估之前,需要先谈一谈与Automotive SPICE相关的组织。
2.1 Automotive SPICE相关的组织
在Automotive SPICE领域,没有机构去管理“评估”,只是有机构去管理“评估师”。这个管理评估师的机构就是iNTACS(国际评估师认证机构,INTernational Assessor Certification Scheme)。iNTACS定义了评估师的级别划分,以及级别晋升和级别维持的条件。Automotive SPICE评估师的级别从低到高分别为:Provisional Assessor, Competent Assessor, Principal Assessor。
晋升到competent Assessor或Principal Assessor,或维持competent Assessor或Principal Assessor资质时,其条件之一就是需要实施Automotive SPICE评估:
作为Assessor晋升证据(或维持资质的证据)的评估要求包括:
评估由至少2个评估师来实施,评估组组长需要Competent Assessor或Principal Assessor,评估组组员可以是Provisional Assessor或Competent Assessor或Principal Assessor
评估的过程范围至少包括项目管理相关的过程、支持类相关的过程和工程类相关的过程
评估的时间需要至少50小时
2.2 Automotive SPICE评估的类型
在1次Automotive SPICE评估时,Automotive SPICE相当于评估的准则(Criteria),而还需要有评估方法,根据所选择的评估方法不同,Automotive SPICE评估分为两种类型,一种是项目能力度评估,一种是组织成熟度评估。
项目能力度评估
遵照ISO/IEC 15504-2 Performing an assessment实施的评估,是项目能力度评估。在这类评估中,是由Sponsor(发起评估的人)确定评估的模型范围(选择哪些过程,这些过程需要评估到几级)、项目范围(评估哪个项目),而Assessor是根据Sponsor的要求实施评估。
(企业想评价哪个项目,评价哪个过程,评价到几级,不是Assessor决定的!)
组织成熟度评估
ISO/IEC 15504-7 TR Assessment of organizational maturity定义的是组织成熟度评估的评估方法,在组织成熟度评估时:Sponsor确定被评估的组织,以及目标级别;由Assessor根据对被评估组织进行分析,之后进行项目抽样(使得被抽样的项目能代表整个组织的水平),然后通过对被抽样项目进行预定义过程的评估,进而得出组织的过程成熟度水平。
简单来说:在组织成熟度评估时,是由Assessor确定被评估的项目,而过程范围也是需要预定义的(应该由Automotive SPICE的Owner来定义,详细的原因,这里不再赘述,读者可以思考思考~~)
组织成熟度评估在业界很少被用到,主要的原因是OEM不太认可组织成熟度评估的方式。我分析有两个原因:
OEM更关注的是供应商为其开发的项目的情况如何,而不关注供应商的组织
Automotive SPICE的业界大咖们不希望Automotive SPICE因为组织成熟度的评估方式而商业化(Automotive SPICE还是很高冷的,不像CMMI那么商业化)
基于如上原因ISO/IEC 15504-7在2008年发布之后,至今也还是TR,始终不是一个正式的ISO标准,本文后续的描述,不再讨论组织成熟度评估。
注:此处的标准号都是15504,15504系列标准正在被330XX标准所替代。
2.3 被认可的Automotive SPICE评估
什么样的Automotive SPICE评估才是正式的评估,或者说是被认可的评估呢?
经常经常有人问我这个问题,但这个问题的题干是不完全的。
是被谁认可的评估呢?
举个例子:如果需要OEM A认可的评估,那么这个认可的条件就需要OEM A来定义。OEM A可以指定某个专业的软件过程专家(该专家可能不具备任何Automotive SPICE的Assessor资质),然后只要是该专家实施的评估,OEM A都认可。
所以说,这个问题不能问我,你应该去问那个“谁”
这么分析问题,有点杠精的行为了~~
正式的评估或者被认可的评估,在Automotive SPICE领域引申是指“可以做为Assessor资质维持或资质晋升的证据的评估”,那这样的评估需要满足什么条件呢?这个答案就是在前文(2.1节)中的阐述。
只要满足2.1节所阐述的条件的评估,就可以认为是一个正式的评估和受认可的评估。与实施评估的组织是无关的哦~~,对吗?
2.4 Automotive SPICE评估结果的有效性和有效期
Automotive SPICE评估是在某个时间点,对某个项目中已经实施的过程的能力度进行的评估,评估结果是代表了历史上的某个项目,在历史上的某个时间点的过程能力情况。
评估结果只是对被评估项目有效,对其它项目是无效的。
在VDA Guideline中,增加了12个月有效期的说法:在被评估项目中,如果没有发生变更,则可以认为评估结果在12个月之内是有效的(这个有效是对同一个被评估项目来说的);这里的变更是指过程的变更,包括:开发地点的变更、团队组织结构的调整、人员的更替、开发过程的调整等。
虽然某一次Automotive SPICE评估结果只是对被评估的项目有效,对其它的项目无效。但该次评估结果也往往还是可以在一定程度上反映其它项目的过程能力,特别是当其它项目与被评估项目在项目特征上一致时。
1)比如:某个OEM在考察供应商时,供应商展示了3个月之前实施的一次Automotive SPICE评估结果,则OEM可能会认为:“既然是在这么短的时间之前做的评估,那么该评估结果能代表企业目前的能力”(接受)。如果供应商展示了10年之前实施的一次Automotive SPICE评估结果,则OEM可能会认为:“这是太久之前的一次评估,很难代表企业现在的能力”(不接受)。3个月的时间可以接受,10年的时间不可以接受,那么中间的临界时间点在哪里呢?没有答案哦~~
2)不同的Automotive SPICE能力度级别也会对评估结果的有效性产生影响。
Automotive SPICE能力度二级时,具备相同项目特征的项目之间,其项目过程可以是不一致的;Automotive SPICE能力度三级时,具备相同项目特征的项目之间,其项目过程是一致的,都是遵照了标准的组织过程。基于此,企业的某个项目的某些过程如果达成了Automotive SPICE能力度三级,则客户可能会相信其它项目的过程能力也是如此的。
2.5 评估通过证书
当第三方机构在为某企业实施了Automotive SPICE评估之后,如果评估范围内的过程都达到了目标级别,则第三方机构会应被评估组织的要求,发一个通过Automotive SPICE评估的证书。
注:评估通过证书不是Automotive SPICE评估所要求的。是被评估组织为了其Marketing及Business目的,而要求评估机构颁发的。
Automotive SPICE评估通过证书是Automotive SPICE评估结果的Summary,虽然不同的第三方机构,颁发证书的格式和内容都不尽相同,但为了能客观全面的反映评估结果,一般需要包括如下信息:
被评估的组织及部门(是对某个部门下的项目进行的评估,项目所在的具体部门信息需要体现出来)
评估所遵照的Automotive SPICE模型信息,目标级别
评估方法
评估的项目名称,及评估的过程范围,评估日期
实施评估的组织
评估组组长信息及签名
过程流程图,DFMEA,PFMEA,CP的顺序及关系是怎样的
失效模式分析中包含的两个过程,一个是设计失效模式分析,另一个是生产失效模式分析。两者的区别在于DFMEA是产品开发前期进行评估,并将对风险及可能发生概率进行一个整合;而PFMEA是对产品生产环节进行分析。关注的时间段不同而已,但两者中间是有重叠的地方,就如项目工程师一般跟进到项目试产OK后交给生产,而生产从开始试产时接手。
关于aspice软件开发流程中dfmea和aspice软件开发流程的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。