目录
五.DEVELOPMENT COST OPTIMIZATION
前言
摘要：车辆设计已经进入了一个新的阶段，即软件定义车辆(SDV)，风险控制需要保证功能安全，开发成本需要优化以实现利润最大化。本文的目标是在ISO 26262定义的汽车安全完整性等级(ASIL)分解的基础上，优化具有安全意识的SDV的功能安全要求下的开发成本。为此，提出了功能安全风险评估和开发成本优化两阶段的解决方案。第一阶段开发一种新的快速风险评估(FRA)算法，以评估SDV功能的功能安全风险，包括联合可靠性风险和实时风险。第二阶段提出了一种双重需求保证(dual requirement guarantee, DRG)算法，同时考虑可靠性和实时性要求来优化开发成本。实验表明，该两阶段方案在保证功能安全的同时，降低了20%-24%的开发成本。
一、INTRODUCTION
1.研究目的
随着智能网络互联和自动驾驶技术的快速发展，汽车已经从孤立的信息孤岛走向互联网络，数据驱动的“软件定义”的重要性日益凸显。越来越多的功能可以通过软件实现，软件的成本占到汽车成本的近40%，软件是汽车中迭代最快、最容易个性化的部分。软件定义车辆(SDV)已经成为汽车行业的新兴趋势。然而，确保SDV功能的安全运行和降低其开发成本对汽车制造商和信息技术(IT)制造商来说都是一个巨大的挑战。
ISO26262是SDV中针对安全相关系统和软件开发的功能性安全标准，ISO 26262的第一版和第二版分别于2011年11月和2018年12月发布，分别为 Iso 26262:2011 Road Vehicles—Functional Safety和Iso 26262:2018 Road Vehicles—Functional Safety。ISO 26262使开发过程结构化和系统化，但随着开发成本的增加，由于SDV功能开发和测试的额外工作量。开发成本表示在开发生命周期中开发SDV功能的工作量。由于汽车制造商希望在激烈的市场竞争中获得高额的产品利润，SDV是一种对成本非常敏感的系统，需要避免过高的成本。幸运的是，SDV功能的开发成本可以通过汽车安全完整性级别(ASIL)分解部分降低。ISO 26262提供了四个ASIL，包括ASIL A(最低ASIL)、ASIL B、ASIL C和ASIL D(最高ASIL)。功能的ASIL值反映了其风险程度。具有更高ASIL的功能意味着更高的风险和更大的消除或减轻风险的努力。通过ASIL分解，一个高ASIL执行的任务可以分解为几个低ASIL执行的任务，提高了[9]的可靠性。此外，与在高ASIL[8]中执行的任务相比，在低ASIL中执行的任务的开发成本可以降低至少25%。但是ASIL分解对SDV功能的功能安全要求保证产生了正负两方面的影响。
一方面，ASIL分解可以通过任务冗余机制增强SDV功能的可靠性(即生存概率)。可靠性是ISO 26262中重要的功能安全性能之一。因此，可靠性要求必须保证一个安全的SDV功能。
另一方面，ASIL分解可能会由于冗余增加而导致SDV功能的响应时间过长。考虑到SDV是典型的实时系统，响应时间也是重要的功能安全特性之一。因此，有必要保证实时需求一个安全感知的SDV功能。
2.挑战
在ISO 26262中，风险意味着同时考虑暴露和危害的严重程度。暴露是指伤害发生的概率，严重程度是指伤害的程度。严重程度、暴露程度和可控性共同构成了相应的ASIL。为了控制风险，防止各种安全事故的发生，必须在设计初期对具有安全意识的SDV功能进行严格的风险评估。
在风险评估阶段，如果任何可靠性或实时需求得不到保证，功能安全需求就不能得到保证。谢国琪老师等人研究了一个SDV功能的开发成本优化问题，遗憾的是，本研究只考虑了可靠性要求，而忽略了实时性要求。在ISO 26262中，故障行为被定义为SDV功能的非预期行为，这与SDV功能的设计意图有关。可靠性与失效有关，而错过最后期限则与非预期行为有关。为了保证SDV功能的功能安全要求，必须同时保证可靠性和实时性要求。但在实际应用中，提高可靠性需求保证的可靠性与缩短实时需求保证的响应时间存在矛盾。考虑到ASIL分解使用的上述影响，考虑SDV功能的功能安全要求，需要优化开发成本。
3.贡献
据我们所知，这是研究SDV中同时考虑实时性和可靠性要求的开发成本优化的第一个工作。提出了功能安全风险评估和开发成本优化两阶段方案。本文的贡献如下。
(1)在我们的两阶段方案中，第一阶段通过提出基于ASIL分解的快速风险评估(FRA)算法，评估SDV功能的功能安全风险(包括联合可靠性风险和实时风险)。
(2)第二阶段通过提出基于ASIL分解的双需求保证(dual requirement guarantee, DRG)算法优化开发成本。
(3)实验表明，所提出的两阶段方案在保证功能安全的同时，降低了20%-24%的开发成本。
与[8]、[11]、[13]-[15]中的研究相比，本文将风险评估作为开发成本优化的前提。另外，与以往独立保证可靠性和实时性需求[9]或只保证一个需求[11]的工作相比，我们的技术同时考虑了可靠性和实时性需求，从而降低了开发成本，满足了SDV功能的实际需求。
二、RELATED WORK
如前面所指出的，开发成本代表完成SDV功能开发的工作量。Jorgensen等人系统地回顾了[16]中的软件开发成本估算，总结出304种软件成本估算工具。Rajper等人在[17]中提供了一项关于软件开发成本估算的新调查。下面，在软件程序员熟练使用这些工具的前提下，对开发成本优化的相关工作进行回顾。
在工程师项目区，在engineer project area中，一个软件项目被分解为多个任务，将熟练的程序员分配到合适的任务中是一个人员分配不平衡的问题。Wang等研究了针对不同需求寻找最优人员配置方案的软件开发成本优化问题。Zhang等分析了开发成本对利润最大化和绩效优化的影响。
开发成本优化已经在汽车领域得到了积极的研究。Tamas-Selicean等人首先建立了车辆[8]、[13]的功能开发成本模型，其中禁忌搜索解决方案用于优化开发成本，同时保证所有功能都是可调度的。[8]、[13]激发了更多关于混合临界系统功能开发成本优化的研究。例如，Gan等在[14]中利用遗传求解方法研究了开发成本优化问题。与[8]不同，[13]使用的是分区架构，[14]不考虑分区架构。此外，Wei等[15]将关键路径禁忌搜索解与消息移动策略相结合，优化了开发成本;这样的组合可以减少递推高程对开发成本优化的影响。
虽然[8]，[13]-[15]对开发成本建模和优化做出了贡献，但在使用ASIL分解时，可靠性要求不被考虑。谢国琪老师等通过ASIL分解在保证可靠性需求的同时优化了SDV功能的开发成本，提出了可靠性目标(MDCRG)最小开发成本的解决方案。然而，MDCRG仅仅考虑了可靠性要求，而忽略了实时性要求。在接下来的章节中，我们将重点关注在保证SDV功能的功能安全需求的同时优化SDV功能的开发成本。
三、PRELIMINARIES
A.ASIL测定和分解
可控性是指ISO 26262中驾驶员通过及时响应来规避危害的能力。在ISO 26262中，有四个严重级别，即S0-S3，五个暴露级别，即E0-E4，以及四个可控性级别，即C0-C4。
表I给出了ASIL测定，它是由严重程度、暴露和可控性的组合决定的。注意，质量管理(QM)意味着开发SDV功能不需要调用SDV功能的功能安全需求。
在本文中，我们考虑了一个具有ASIL D的高度安全意识的SDV功能(例如，具有最高风险程度的线旁制动功能)。根据表I, ASIL D只有一种组合(即S3, E4, C3)。即严重程度危及致命伤(即S3)，暴露概率高(即E4)，可控性不可控(即C3)。
对于给定的SDV功能，严重性和可控性是固定的;因此，我们让{LA, LB, LC, LD}代表本研究中{E1, E2, E3, E4}的暴露集。
ASIL分解有两种类型的冗余:同质冗余和异构冗余。此外，同构冗余有两种主备份复制:被动复制和主动复制。由于任务间的独立性，本研究采用同质冗余和主动复制。图1显示了ISO 26262的ASIL分解指南。
SDV功能的所有任务都假定在ASIL D(简称D)中执行。图1(d)显示，D有以下三种ASIL分解格式(简称格式)。注意QM意味着开发一个SDV功能不需要像前面解释的那样调用SDV功能的功能安全需求。因此，对于D存在三种方案，即“C + A”、“B + B”和“D”。从图1(c)可以看出，对于C有两种方案，即“B + A”和“C”。图1(b)表明，b实际上有两种方案，即“A + A”和“B”。因此，‘B + 2×A’和‘4×A’也是D通过C和B分解后的方案。最后对D的五种方案进行了优化，分别为“C + A”、“B + B”、“D”、“B + 2×A”、“4×A”，如图2所示。
表示为U = {U1,U2，…，U|U|}为SDV中异构ECU集合，其中|U|为集合U的大小。SDV是一种分布式系统，其中所有ecu通过共享的控制器区域网络(CAN)彼此通信。由于功能中的优先约束，一个功能(例如从传感器到执行器的端到端计算、通信和控制过程，如线接制动器的功能)被建模为一个有向无环图(DAG)，让我们考虑将SDV功能实现为软件任务。
本文采用广泛使用的动机性SDV功能(DAG)，如图3[11]所示。参数G = (T, W, M, C)具体解释如下:
1)任务模型:用T表示G中的一个任务集，Ti∈M为G的第i个任务。激励SDV功能(图3)有六个具有优先约束的任务。pred(Ti)是Ti的直接前辈任务集，succ(Ti)是Ti的直接后继任务集。例如，在激励SDV功能中，pred(T3) = {T1,T2}和succ(T3) = {T5}。Tentry和Texit分别是SDV功能的进入和退出任务。例如，图3中的Tentry= T1和Texit= T6。W = |T|*|U|*4，其中Wi,k,h为在ECU Uk和ASIL Lh执行Ti的最坏情况执行时间(WCET)。
2)消息模型:M为通信消息集，Mi,j∈M为Ti到Tj的通信消息。Ci,j∈C为Mi,j的最坏情况响应时间(WCRT)。例如，在激励SDV功能中C1,2=9和C1,3=12。如果将Ti和Tj分配到同一个ECU，则通信响应时间为0。
C.开发成本模型
开发成本不是一个精确的值，而是一个估算值，一个任务的开发成本可以由设计者估算出来。原因是开发过程是在ISO 26262标准的指导下进行系统评估和实施的过程。在开发具有安全意识的SDV功能时，开发人员通常是高质量软件开发的熟练人员。根据同构冗余的使用，由这些工作人员开发的相同任务的多个副本实质上花费几乎相同的开发时间。同一任务的多个副本在各自的ecu中执行的开发成本在同一ASIL中基本相同。设V为|T|×4矩阵，其中vi,h为在ASIL Lh中执行Ti的开发成本。每个任务都有可变的开发成本，在可变的ASILs中执行。在高ASIL中执行的任务的开发成本要高于在低ASIL中执行的任务。例如，表II中T1、LA组合形成的值5为在LA执行的T1的开发成本(即 v1,A = 5 kEuros)
用DevCost(Ti，方案g)表示方案g下Ti的开发成本。每个任务的每个方案的开发成本是其副本的开发成本之和，如[11]所示。
其中vi,h为在ASIL Lh执行Ti的开发成本，如III.B节所示。用schemesc(Ti)表示Ti的分配方案。SDV功能的开发成本为
D.可靠性模型
本研究考虑了SDV功能中任务的瞬态失效(例如，位翻转)，并且这种失效遵循泊松分布。将ECU Uk的故障率用仿真模型(upc)表示，则Ti在Uk和Lh执行的可靠性为
R (Ti,Uk, Lh) = e−λkWi,k,h,
其中Wi,k,h表示任务Ti在ECU Uk和ASIL Lh中执行的WCET，如前所述。正如ISO 26262所指出的，在设计阶段，同构冗余主要集中于控制硬件中的瞬态或随机故障。因此，本文利用硬件故障概率来求得任务正常执行的存活概率。为了验证一个任务是否发生了硬件故障，需要在硬件层面采取一些措施来抵抗软错误并执行必要的恢复工作，这超出了本文的范围。
通过执行ASIL分解，每个任务有1-4个副本。每个方案的副本数量是固定的，如III.A节所指出的。用num(方案g)表示方案g的副本数。例如，方案4有3个副本，如图2所示。如果成功完成Ti的一个副本，Ti就可以成功完成，因此，Ti在分配方案方案g下的可靠性为
其中Ti^x是Ti的第x个副本。Upr(Ti^x)和Lcl(Ti^x)分别是分配给副本Ti^x的ECU和ASIL。等式(3)与(4)的不同之处在于，(3)具有给定ECU和ASIL中Ti的可靠性，而(4)具有给定方案中Ti的可靠性。SDV功能G的可靠性是其所有任务的乘积，即，
其中，方案sc(Ti)为为Ti选择的方案。考虑到CAN总线的故障率仅为ECU故障率的1/1000，本文只考虑ECU故障，抛弃通信故障。
我们不能保证所有的SDV功能都是100%可靠的。因此，SDV功能的可靠性是合理的，在可靠性要求得到保证的情况下可以满足标准。但是，在ISO 26262中并没有“可靠性要求”的定义，但是在给定的暴露水平下的可靠性要求可以推断出来，如表三所示。例如，暴露E2的可靠性要求是0.99。
四. RISK ASSESSMENT
在优化开发成本之前，我们必须评估SDV功能的功能安全风险。在功能安全要求得到保证后，可以进行后续的开发成本优化。因此，第一阶段是评估SDV功能的功能安全性，第二阶段是优化开发成本。
值得注意的是，与以往独立保证可靠性和实时性要求或只保证一个要求的工作相比，我们的技术同时考虑了可靠性和实时性要求，从而降低了开发成本，满足了SDV功能的实际需求。
A.可靠性风险评估
考虑到方案5(图2(e))在四个LA级别上执行的冗余副本最多，且在较低ASIL下执行的任务与在较高ASIL下执行的任务相比，其WCET值小于或等于，因此必须在方案5中获得最大的可靠性。只要Ti选择4个故障率最低的ecu, Ti的最大可靠性为
其中Ulow_1表示故障率最低的ECU，其次是Ulow_2、Ulow_3、Ulow_4。那么，SDV功能G的最大可靠性为
Rmax(G)应大于或等于可靠性风险控制的可靠性要求Rreq(G)，如等式(8)所示:
否则，无法访问Rreq(G)。例如，假设ECUs U1、U2、U3和U4的失败率分别为:sp1 = 0.01, sp2 = 0.02, sp3 = 0.03, sp4 = 0.04。利用等式（6)可以知道任务的最大可靠性值，如表4所示。根据公式(7)，SDV功能的最大可靠性为Rmax(G) = 0.99968，可靠性要求假设为Rmin(G) = 0.9。在这种情况下，Rreq(G)是可达到的，可靠性风险是可控的，因为根据等式8
0.99968 >=0.9,
B.实时风险评估
在可靠性风险可控之后，对实时风险进行评估。我们的目标是判断SDV功能的响应时间是否在实时性要求之内，同时又保证了可靠性要求。形式上，一种是优化响应时间RT(G)，使之满足以下要求
RT(G) <=RTreq(G),
在保证可靠性要求的同时:
R(G) <= Rreq(G).
在多处理器(multi- ecu)中，在服务质量(QoS)要求(如可靠性要求或实时要求)下调度任务的最优性(如最小化或最大化)通常是NP-hard.因此，很难获得SDV功能的最小响应时间。提出了异构最早完成时间(HEFT)算法来近似求解在异构系统中低时间复杂度调度DAG的最优解。为了避免在风险评估阶段浪费太多时间，影响开发进度，我们采用快速列表调度进行实时风险评估。
为了实现快速的风险评估，我们采用了可靠性需求迁移策略。每个任务在保证其可靠性要求的前提下，以最小的EFT选择方案和相应的副本分配。
1)任务的可信度要求:注意我们的可信度风险评估遵循[9]和[11]。为了完整起见，我们在这里包括一些细节。在此基础上，我们将开发一个新的风险评估指标，称为AFT，它将同时考虑Eq.(12)中的可靠性风险评估和实时风险评估。
[23]中提出了一种策略，将功能的可靠性需求迁移到每个任务的可靠性需求。[23]在保证可靠性要求的同时优化了冗余，通过容错将Eq.(9)计算得到的任务上部可靠性预分配给每个未分配的任务。
[11]采用将任务的最大可靠性预分配给每个未分配任务的策略，在保证可靠性要求的前提下，优化开发成本。但是，考虑到ASIL分解本质上是容错的一种特殊情况，使用与[23]相同的策略来计算任务的可靠性要求更有效(更多细节将在实验中讨论)。
保证本文可靠性要求的具体策略如下。假设当前任务为Ts(y)(即其中s(y)表示分配的第y个任务。s(y)将两个任务组分开。
(1)第一个任务组是{Ts(1)，Ts(2)，…，Ts(y−1)}，任务已经分配在其中。
(2)第二个任务组为{Ts(y+1)，Ts(y+2)，…，Ts(|T|)}，其中未分配任务。
任务按照ranku值的降序排列优先级。ranku是DAG[22]中经典的任务优先级规则，由[9]计算
Wi,D是ASIL D中任务Ti执行的平均WCET。表IV列出了动机性SDV功能中所有任务的排序值。G中的任务分配顺序为{T1,T2,T3,T5,T4,T6}。分配Ts(y)时，保证SDV功能G的可靠性
根据等式(9)中任务的上部可靠性Rup(Ti)，那么R Ts(y)必须保证
任务Ts(y)的可靠性要求如下。
Ts(y)的实际可靠性需要保证
R(Ts(y)) >= Rreq(Ts(y)).
2)任务分配:将Ts(y)分配给EFT最小的ECU，同时保证Ts(y)的可靠性要求Rreq(Ts(y))。在任务分配中，选择最小的EFT是一种常用的解决方案。
ASIL分解优化响应时间的细节如下:在保证等式(11)可靠性要求的前提下，遍历所有可用ecu，只优化每个任务的实际完成时间(AFT)。因此，该AFT度量联合考虑了可靠性风险评估和实时风险评估，这是本工作的贡献。Ti的分配方案方案sc(i)由
EFT(Ti，方案g)的计算方法是
Ti的副本按照ASILs的升序排列优先级。这是因为在低ASIL和ECU下执行的任务比在高ASIL和该ECU下执行的任务具有更低的WCET，从而得到每个方案的局部最优副本。注意，R(Ti，方案g)是根据公式(4)计算的。
一种可能的情况如下。这五种方案的任务分配都是基于EFT的，都不能保证任务的可靠性要求。在这种情况下，我们不再追求最小的EFT，而是直接考虑由Eq.(6)计算出的方案的最大可靠性。我们将当前任务的4个ASIL A副本全部分配给4个故障率最低的ecu。
C.FRA算法
下面提出了FRA算法(算法1)，在保证可靠性要求的前提下，获得SDV功能的响应时间。
算法1 FRA算法
Input: U = {U1,U2,...,U|U|}, {LA, LB, LC, LD}, G,Rreq(G)
Output: RT(G)
1:按照ranku(Ti) (等式(10))值降序排列rank_list中的任务;
2: while (rank_list中有任务) do
3: Ti← Ts(y)← task_list.out();
4:利用等式(11)计算Rreq(Ti);
5: for (g ← 1;g ≤ 5;g++) do
6:利用公式(13)计算EFT(Ti，方案g)
7:利用公式(4)计算R(Ti，方案g);
8: end for
9:在保证Ti可靠性要求Rreq(Ti)的同时，选择EFT最小的方案;
10:如果(五种方案都不能保证Ti的可靠性要求)Then
11.将Ti的4个LA副本(即方案5)分配给4个失败率最低的ecu，因为该方案在5个方案中具有最大的可靠性;
12: end if
13:利用公式(12)计算AFT(Ti);
14: end while
15:利用公式(5)计算可靠性R(G);
16: RT(G) ← AFT(Texit).
FRA通过可靠性预分配将SDV功能的可靠性要求迁移到任务的可靠性要求。每个任务在保证可靠性要求的前提下，以最小的EFT选择ASIL分解方案和相应的副本分配。
(1)任务的优先级。FRA按照第1行中ranku值的降序排列rank_list中所有任务的优先级。
(2)任务的信度要求。FRA使用第4行等式(11)计算当前任务Ti的可靠性要求。
(3)任务完成时间。如前所述，可靠性最大化经常与响应时间最小化相冲突。如何处理这种冲突是FRA算法的关键。在第9行，FRA在保证Ti的可靠性要求Rreq(Ti)的同时，选择EFT最小的ASIL分解方案。也就是说，FRA不追求每个任务的信度值的最大化，而是计算出能够保证信度要求的最小EFT的ASIL分解方案。如果5个ASIL分解不能保证Ti的可靠性要求，则在LA执行4个副本(即。由于该方案在5个方案中可靠性值最大(第10-12行)，因此该方案在故障率最低的4个ecu中执行。
(4)功能的可靠性和完成时间。实际的可靠性和响应时间在FRA的第15和16行中计算。
下面，我们将证明FRA的时间复杂度为O(|T|^2×|U|^2)。
(1)调度SDV的所有任务需要遍历所有任务，占用O(|T|)时间(第2-14行)。
(2)计算当前任务的可靠性要求Rreq(Ti)需要遍历其所有任务，需要O(|T|)时间(第4行)。
(3)计算当前任务的EFT值需要O(|T|×|U|^2)时间(第6行)，因此FRA的时间复杂度为O(|T|^2×|U|^2)。
D. FRA算法的例子
图4显示了FRA-generated 任务的激励SDV功能的映射，其中绿色、蓝色、黄色和红色分别表示在ASIL A、ASIL B、ASIL C和ASIL D中执行的副本。在本例中，T1、T3和T6选择方案2;T2挑选方案5;T4和T5选择方案4。由于没有选取方案2、方案4、方案5，根据表II, ASIL C和ASIL D中没有执行副本。图4中的箭头表示具有依赖关系(即优先约束)的任务之间产生的通信。实际响应时间为RT(G) = 95并保证
RT(G) = 95 <=RTreq(G) = 100.
SDV功能的实际可靠性为R(G) = 0.906754并保证
R(G) = 0.906754 >=Rreq(G) = 0.9.
即对动机性SDV功能进行风险评估的结果是能够保证SDV功能的功能安全需求。在接下来的章节中，我们可以在保证SDV功能的功能安全要求的前提下实现开发成本优化。
五.DEVELOPMENT COST OPTIMIZATION
之前的工作是独立的保证可靠性和实时性要求，或者只保证一个要求，而我们的开发成本优化技术是同时考虑可靠性和实时性要求，从而降低了开发成本，满足了SDV功能的实际需求。
第一阶段的FRA算法保证了SDV功能的功能安全要求(如图4所示)，但不涉及开发成本优化。本节的第二阶段旨在确定每个任务的所有副本的ECU和ASIL分配，以优化SDV功能G的开发成本:
(14)
在保证可靠性要求的同时:
(15)
并保证实时性要求:
RT(G) <= RTreq(G)
在优化开发成本的过程中，还需要同时保证每个任务的可靠性和实时性要求。首先说明如何保证可靠性要求，然后说明如何保证实时性要求。
A.可靠性要求保证
我们按照以下步骤说明了保证SDV功能功能安全要求的过程:
1) 任务的优先级:与FRA不同，FRA按照ranku值的降序排列任务的优先级,我们将根据FRA生成的AFT(Ti)值的降序排列任务的优先级，因为在某些ecu中，FRA-generated生成的RT(G)和实时需求RTreq(G)之间存在一些slacks。例如图4中的slacks在RT(G) = 95和RTreq(G) = 100之间。因此，将依次优化T6、T5、T3、T4、T2、T1。
2)任务的信度要求:由于FRA已知所有任务的初始实际信度值，因此对当前重新分配任务Ti的可信度要求为
(16)
注意，在计算当前任务Ti(即Ts(y))时，其他任务的可靠性值应该保持当前的单个值。
B.实时需求保证
1)任务的实时需求:当前任务Ti由于任务之间的依赖关系，其实时需求受到后续任务的限制，即:
其中ET(Ti, Sk)表示Ti在Uk可用的slacks的结束时间。注意Ti在不同的ecu中有单独的RTreq(Ti,Uk)。考虑到我们的目标是重新分配Ti，它之前由FRA分配的副本必须被删除。
2)任务的最早开始时间(EST):类似于RTreq(Ti,Uk)，我们需要计算EST，因为它与之前的任务存在依赖关系。注意，每个任务在不同的ecu中有EST(Ti,Uk)，如下:
其中ST(Ti, Sk)表示Uk Ti可用的slacks的开始时间。例如，图4中所有ecu中T6的ESTs和RTreq可得为
3)可插入的ASIL Level (IAL):考虑到所有的slacks都已经得到，我们可以为每个ECU计算IAL来得到方案分配。例如，所有ecu中t6的IAL值如下:
4)方案的可靠性:基于IAL，可以计算出每个可能方案的可靠性。我们首先根据下面的可信度值，将最重要的信息降序排列，以获得方案的高可信度:
基于图2(d) (LA, LA, LB)中方案4对T6可靠性的计算，我们进行如下搜索过程
(1)选择R(T6,U1,LA) = 0.960789，因为在所有LA候选中，R(T6,U1,LA)的可靠性最高。
(2)然后我们为LA选择第二高的可靠性，可以选择R(T6,U2, LA) = 0.886920。
(3)在所有LB候选中，我们选择最高的可信度R(T6,U1, LB) = 0.951229。
最后，根据公式(4)计算，Ti与方案4的可靠性为R(T6，方案4)= 0.999382。
C.优化开发成本
ASIL分解优化开发成本的策略是:在保证可靠性和实时性的前提下，为每个任务选择开发成本最小的方案。换句话说，Ti的分配方案方案sc(i)和开发成本DevCost(Ti)是由
提出了算法2所示的DRG算法。通过DRG，在优化开发成本的过程中，共同保证了各任务的可靠性和实时性要求。
(1)任务的优先级。DRG根据第1行中ranku值的降序排列rank_list中的所有任务的优先级。
(2)任务优先级。DRG根据第1行中AFT值的降序排列aft_list中的所有任务的优先级。在下面，将遍历所有任务。
(3)任务的可信度要求。DRG使用第4行中公式(16)计算当前任务Ti的可靠性要求。
(4)任务的实时性要求。DRG利用公式(17)计算当前任务Ti的实时需求，然后在第5-9行重新分配Ti得到可用的ASIL分解方案。
(5)任务的开发成本。在第10行，DRG利用Eq.(18)在保证Ti可靠性和实时性要求的同时，计算出最小的开发成本。也就是说，DRG不追求每个任务的可靠性最大化和响应时间最小化，而只追求在保证任务的可靠性和实时性要求的条件下，开发成本最小的ASIL分解方案。
(6)功能的可靠性和开发成本。在第12和13行，DRG计算了SDV功能的可靠性和开发成本。
由于FRA和DRG在结构上的相似性，可以看出DRG的时间复杂度与FRA相同，也是O(|T|^2×|U|^2)。
Algorithm 2 The DRG Algorithm
Input: U = {U1,U2,...,U|U|}, {LA, LB, LC, LD}, G,Rreq(G), RTreq(G), and FRA-generated 分配
Output: DevCost(G)
1:优先在一个列表aft_task_list任务根据AFT值降序使用公式 (12);
2: while (aft_task_list中有任务) do
3: Ti← af t_task_list.out();
4:利用公式(16)计算Rreq(Ti);
5:在ECUs中清除当前任务Ti的所有副本的分配;
6:基于单个ecu，获取当前任务Ti的EST(Ti,Uk)和RTreq(Ti,Uk);
7:在单个ecu中获取当前任务的slacks;
8:在单个ecu中获取当前任务Ti的每个slack的可用ASILs;
9:将当前任务Ti所有可用的ASILs按信度值降序排列;
10:利用公式(18)计算最小开发成本DevCost(Ti)，同时保证Ti的可靠性和实时性要求;
11: end while
12:利用公式(15)计算可靠性R(G)；
13:利用公式(14)计算开发成本DevCost(G)。
D. DRG算法的例子
图5为DRG生成的动机SDV功能g的任务映射图。与图4相比，使用FRA, DRG进一步分解T1、T4、T3、T5、T6的ASILs，在保证可靠性和实时性要求的前提下优化开发成本。我们计算了图4中使用FRA的开发成本为160 kEuros，而使用DRG则减少到139 kEuros(图5)。
六.EXPERIMENTAL EVALUATION
我们采用[11]、[14]的现实生活中的SDV功能(图6)进行实验。有六个关闭阀关闭阀的功能:在现实中的功能块T1-T7用于发动机控制器,T8-T11用于自动齿轮箱,T12-T17用于防抱死制动系统,T18-T19用于车轮角传感器,T20-T24用于悬浮控制器,和T25-T31用于身体的工作。
SDV的功能参数是根据实际部署提前知道的。
(1) ECUs的失败率在1小时内在10^ - 5-10^ - 4范围内。
(2)信息的WCRTs在100微秒至400微秒范围内。
(3)ASIL A、ASIL B、ASIL C和ASIL D中执行的任务的WCETs在100 μs–400 μs, 500 μs–800 μs, 900 μs–1200 μs, and 1300 μs-1600 μs的范围内。
(4)任务开发成本在0-30 kEuros范围内。
(5)仿真创建16个异构ecu。
功能的最小开发成本由
任务Ti的最小开发成本是DevCostmin(Ti)
DevCostmin(G)是最优的，因为它们既不考虑可靠性也不考虑实时需求，我们在本文中将这种解决方案命名为最小开发成本(MDC)。MDCRG是[11]中提出的最先进的解决方案，在保证可靠性要求的同时优化开发成本。因此，本文比较的解决方案分别是MDC、MDCRG、FRA和DRG。
1) Experiment 1:比较固定实时性要求和不同可靠性要求下实际SDV功能的开发成本。由于信度要求在E3和E2暴露范围内(见表III)，信度要求从0.9变化到0.99，增量为0.01。同时，将SDV功能的最大可靠性要求设为0.999999，视为E1的可靠性要求。因FRA通过风险评估，实时需求稳定在RTreq(G) = 4,333μs。不同可靠性要求下SDV功能的开发成本如图7所示。
(1)通过式(19)计算，MDC总是得到641 kEuros的最小开发成本。但是MDC不能保证SDV功能的功能安全性要求，因为它的响应时间值为7,139μs，不在实时要求的4,333μs范围内。MDC-generated的可靠性固定在0.0944，远远低于所有的可靠性要求。
(2) MDCRG、FRA和DRG总能得到大于或等于相应可靠性要求的可靠性值，从而在任何情况下都能保证可靠性要求。
(3) MDCRG的开发成本低于DRG，但可靠性要求为0.97的情况除外。然而，MDCRG在所有情况下都产生非常大的响应时间值(> 10000μs)，因此它不能保证SDV功能的功能安全性要求。原因是MDCRG预先为每个未分配任务分配了最大的可靠性，而不使用容错。这种预分配方案非常悲观，并且会导致响应时间过长。
(4)该功能的最大开发成本为
其中DevCostmax(Ti)表示任务Ti的最大开发成本:
在MDCRG、FRA、DRG三种解决方案中，FRA通过公式(20)总能获得1016kEuros的最大开发成本。但可以保证SDV功能的功能安全要求，其获得的响应时间值固定在4,333μs，可靠性固定在0.9999997。
(5)当DRG的实际响应时间值等于4333μs，且实际可靠性值超过可靠性要求时，DRG能够保证功能安全要求。此外，DRG-generated的可靠性值总是大于但接近相关的可靠性要求。差距最多为0.008。
(6) DRG-generated的开发成本不是固定的，而是随着可靠性要求的增加而降低的。开发成本的变化是因为实际的可靠性值随着可靠性需求的增加而变化，因此开发成本也会由于ASIL分解而变化。此外，DRG获得的开发成本在791 kEuros到852 kEuros之间。也就是说，与FRA相比，DRG可以降低高达20%的开发成本，同时保证SDV功能的功能安全要求。
(7)虽然MDCRG在大多数情况下的开发成本低于DRG，但它不能保证SDV功能的功能安全需求，因此MDCRG不适合SDV功能的功能安全感知设计。然而，在可靠性要求为0.97的情况下，DRG比MDCRG获得的开发成本要少。该方法通过容错将任务的上位可靠性预先分配给每个未分配任务，从而证明了开发成本优化的可行性。
2)Experiment 2:这个实验比较具有固定可靠性要求和不同实时性要求的真实SDV功能的开发成本。实时需求从RTFRA(G)增加到1.9×RTFRA(G)，增量为0.1×RTFRA(G)，其中通过FRA得到RTFRA(G) = 4333μs。可靠性要求固定在0.9。不同实时需求下实际SDV功能的开发成本如图8所示。
(1) MDC仍然获得与图7中相同的641 kEuros的开发成本。原因是MDC不关心不同的可靠性和实时需求，因此它的开发成本不会随着不同的可靠性或实时需求而变化。
(2) MDCRG和FRA也获得了一致的开发成本，分别为771 kEuros和1016 kEuros，如图8所示。原因是MDCRG和FRA都不关心不同的实时需求。
(3)DRG-generated的开发成本不固定，随着实时性要求的增加而降低。开发成本从852 kEuros减至681 kEuros。原因是随着实时需求的增加，有更多的slacks可适用。因此，可以插入这些slacks的方案越多，选择开发成本最小的方案的机会也就越多，如等式(18)所示。
(4)当实时需求大于或等于6499.5μs时，DRG获得的开发成本低于MDCRG。研究结果表明，DRG在松散（低）实时需求下的开发成本优化方面是高效的。
3)Experiment 3:本实验演示了针对不同任务数量的合成SDV功能的开发成本。使用任务图生成器生成合成的SDV功能。根据综合功能的参数设置要求，将通信计算比设置为1，形状参数设置为1，异构因子设置为0.5。合成SDV功能的任务数从50增加到100，增量为10。实时要求固定在由FRA获得的RTFRA(G)，可靠性要求固定在每个SDV功能的0.9。不同数量任务的合成SDV功能的开发成本如图9所示。
(1)所有解决方案的开发成本都是随着任务数量的增加而增加的，因为一个SDV功能的开发成本是所有任务的开发成本之和，任务越多，开发成本就越大。
(2)与实验1和实验2的结果相似，MDC和FRA解决方案仍然分别产生最小和最大的开发成本。而MDC-generated的可信度值在0.06-0.22之间，远低于0.9的信度要求。响应时间值不稳定，超过了0.9的实时要求。
(3) MDCRG在大多数情况下比DRG的开发成本更低，最大差异为120 kEuros，但MDCRG无法保证SDV功能的功能安全要求。
(4)在任何情况下DRG的开发成本都比FRA低，在保证SDV功能功能安全要求的同时，DRG的开发成本比FRA可降低高达20%-24%
以上三步有效的实验结果表明，FRA与DRG的结合对于现实世界中的SDV功能具有较好的开发成本优化能力，对于大规模的SDV功能的开发成本优化仍是有效的。总之,DRG在保证SDV功能功能安全性要求的同时，对现实世界和合成的SDV功能都有较好的效果。
七.CONCLUSION
在保证SDV功能安全要求的同时，研究SDV功能的风险评估和开发成本优化。与之前的技术相比，我们的技术更符合功能安全标准的要求，因为实时性和可靠性要求是结合在一起的。此外，我们的技术在大规模SDV功能的开发成本优化方面是有效的。实验表明，该两阶段方案在保证功能安全的同时，降低了20%-24%的开发成本。
参考文献
[1] D. Jiang, L. Huo, Z. Lv, H. Song, and W. Qin, “A joint multi-criteria utility-based network selection approach for vehicle-to-infrastructure networking,” IEEE Trans. Intell. Transp. Syst., vol. 19, no. 10,pp. 3305–3319, Jan. 2018.
[ 2 ] X.Xu,Q.Wu,L.Qi,W.Dou,S.-B.Tsai,and M.Z.A.Bhuiyan ,“Trust-aware task offloading for video surveillance in edge computing enabled Internet of vehicle,” IEEE Trans. Intell. Transp. Syst., early access, Jun. 25, 2020, doi: 10.1109/TITS.2020.2995622.
[3] G. Luo, J. Li, L. Zhang, Q. Y uan, Z. Liu, and F. Y ang, “Sdnmac:A software-defined network inspired mac protocol for cooperative safety in vanets,” IEEE Trans. Intell. Transp. Syst., vol. 19, no. 6,pp. 2011–2024, Mar. 2018.
[4] J. Chen et al., “Service-oriented dynamic connection management for software-defined Internet of vehicles,” IEEE Trans. Intell. Transp. Syst.,vol. 18, no. 10, pp. 2826–2837, Jun. 2017.
[5] X. Wang, C. Wang, J. Zhang, M. Zhou, and C. Jiang, “Improved rule installation for real-time Query service in software-defined Internet of vehicles,” IEEE Trans. Intell. Transp. Syst., vol. 18, no. 2, pp. 225–235,May 2016.
[6] (Nov. 2011). Iso 26262:2011—Road Vehicles—Functional Safety.[Online]. Available: https://www.iso.org/standard/43464.html
[7] (Dec. 2018). Iso 26262:2018—Road Vehicles—Functional Safety.[Online]. Available: https://www.iso.org/standard/68383.html
[8] D. T˘ ama¸ s-Selicean and P. Pop, “Design optimization of mixed-criticality real-time embedded systems,” ACM Trans. Embedded Comput. Syst.,vol. 14, no. 3, p. 50, May 2015.
[9] G. Xie, H. Peng, J. Huang, R. Li, and K. Li, “Energy-efficient functional safety design methodology using ASIL decomposition for automotive cyber-physical systems,” IEEE Trans. Rel., early access, Jun. 3, 2019,doi: 10.1109/TR.2019.2915818.
[10] M. Alali, A. Almogren, M. M. Hassan, I. A. L. Rassan, and M. Z. A. Bhuiyan, “Improving risk assessment model of cyber security using fuzzy logic inference system,” Comput. Secur., vol. 74,pp. 323–339, May 2018.
[11] G. Xie, Y . Chen, Y . Liu, R. Li, and K. Li, “Minimizing development cost with reliability goal for automotive functional safety during design phase,” IEEE Trans. Rel., vol. 67, no. 1, pp. 196–211, Mar. 2018.
[12] A. Girault and H. Kalla, “A novel bicriteria scheduling heuristics providing a guaranteed global system failure rate,” IEEE Trans. Dependable Secure Comput., vol. 6, no. 4, pp. 241–254, Oct. 2009.
[13] D. Tamas-Selicean and P. Pop, “Optimization of time-partitions for mixed-criticality real-time distributed embedded systems,” in Proc. 14th IEEE Int. Symp. Object/Component/Service-Oriented Real-Time Distrib.Comput. Workshops, Mar. 2011, pp. 1–10.
[14] J. Gan, P . Pop, and J. Madsen, “Tradeoff analysis for dependable real-time embedded systems during the early design phases,”Ph.D. dissertation, Dept. Inform. Math. Model. Inst., Technical Univ.Denmark, Lyngby, Denmark, 2014.
[15] Y.Wei,Y.Le,G. Xie, and L. Zhang, “Development cost optimizationfor multi-functional mixed-criticality embedded systems,” IEEE Access,vol. 7, pp. 88949–88959, 2019.
[16] M. Jorgensen and M. Shepperd, “A systematic review of software development cost estimation studies,” IEEE Trans. Softw. Eng., vol. 33,no. 1, pp. 33–53, Jan. 2006.
[17] S. Rajper and Z. A. Shaikh, “Software development cost estimation:A survey,” Indian J. Sci. Technol., vol. 9, no. 31, p. 51, 2016.
[18] C.Wang,Z.Luo,L.Lin,and M.Daneva,“How to reduce software development cost with personnel assignment optimization: Exemplary improvement on the hungarian algorithm,” in Proc. 21st Int. Conf. Eval.Assessment Softw. Eng., 2017, pp. 270–279.
[19] Y.Zhang,M.Hafezi,X.Zhao,and V.Shi,“The impact of development cost on product line design and its environmental performance,”Int.J.Prod.Econ,vol.184,pp.122–130, Feb. 2017.
[20] G.Xie et al.,“Reliability enhancement towards functional safety goal assurance in energy-aware automotive cyber-physical systems,”IEEE Trans.Ind.Informat.,vol.PP, pp. 1–14, Jul. 2018.
[21] A.Kazeminia, “Reliability optimization of hardware components and system’s topology during early design phase,”J.Amer.Assoc.Pediatric Ophthalmol.Strabismus,vol. 18,no.4,p.e9,2014.
[22] H. Topcuoglu, S. Hariri, and M.-Y . Wu, “Performance-effective and low-complexity task scheduling for heterogeneous computing,” IEEE Trans.Parallel Distrib. Syst., vol. 13, no. 3, pp. 260–274, Mar. 2002.
[23] G. Xie et al., “Minimizing redundancy to satisfy reliability requirement for a parallel application on heterogeneous service-oriented systems,” IEEE Trans. Services Comput., early access, Feb. 7, 2020,doi: 10.1109/TSC.2017.2665552.
[24] (2015). Task Graph Generator. [Online]. Available: https://sourceforge.net/projects/taskgraphgen/
582
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
