软件工程之软件验证计划Software Verification Plan

云纳星辰怀自在2025-03-21 14:36

个人主页 ：云纳星辰怀自在

座右铭 ："++所谓坚持，就是觉得还有希望！++"

本文为基于ISO26262软件验证计划模板，仅供参考。

软件验证计划，包括：

  1. 软件需求验证计划

  2. 软件架构设计验证计划

  3. 软件单元设计验证计划

  4. 软件单元验证计划

1. General

This document is linked to the Project plan (safety plan) of <PrjName>. The verification is carried out in the following different forms:

In the design phases, verification implies the evaluation of the work products of each phase to ensure that they comply with the requirement set out in the previous phase for correctness, completeness and consistency.

In the test phases, verification implies the evaluation of work products of a particular phase within a test environment to ensure that they comply with the requirements set out at that particular phase.

1.1 Purpose

This document outlines the verification activities and the processes used to demonstrate that <PrjName> fulfils ISO26262.

The Software verification plan aims to:

  1. Verify that the defined software requirements are fulfilled.
  2. Clarify the test strategy and test planning for software test.

1.2 Scope

The scope of this document is limited to specification of software verification activities for <PrjName>.

The specification considers the software test objectives, how to make software test plan considering test strategy to carry out software test performance and finally document within test report.

The specification considers the software test strategy and test method.

1.3 Audience

This document is only for used by the staffs and managed within XX. Anyone shall be forbidden to distribute it outside without the written permission from XX.

Copyright © XXX Co., Ltd. 2021.

1.4 Reference Document

Table 1 Associated Regulations

|--------|----------------------------|
| ID | Associated Regulations |
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |

Table 2 Associated Standards

|--------|--------------------------|
| ID | Associated Standards |
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |

Table 3 Associated Documentations

|--------|-------------------------------------------------------------------------------|----------|------------|
| ID | Document ID | Ver. | Author |
| 1 | <XX-SUP-P1T001_XXX-Quality Assurance Plan> | | |
| 2 | <XX-SW-R0T001-SOR_Basic Software Requirement> | | |
| 3 | <XXX-SW-R1T002_Naming Convention for Matlab> | | |
| 4 | <XXX-SW-R1T001_Naming Convention for C-coding> | | |
| 5 | <XXX-SW-G1T001_Guideline for Modelling with Matlab> | | |
| 6 | <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy> | | |
| 7 | <XXX-SW-E2T002_XXX-Software Architecture Design Specification> | | |
| 8 | <XXX-SW-E2T003_XXX-SW Safety Analysis Report> | | |
| 9 | <XXX-SW-E2T001_XXX-Software Architecture Design Strategy> | | |
| 10 | <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy> | | |
| 11 | <XXX-SW-E3T002_XXX-SwUnit Detailed Design and Implementation Specification> | | |
| 12 | <XXX-SW-E4T001_XXX-SW Unit Verification Strategy> | | |
| 13 | <XXX-MAN-M3T011_Review Report-XXX-Software Architectural Design> | | |
| 14 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Design and Implementation > | | |
| 15 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Verification> | | |
| 16 | <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis> | | |
| 17 | <XXX-MAN-M3T010_Checklist-XXX Software Architectural Design> | | |
| 18 | <XXX-MAN-M3T010_Checklist-XXX Software Unit Design and Implementation> | | |
| 19 | <XXX-MAN-M3T010_Checklist-XXX Software Unit Verification> | | |

1.5 Definitions, Acronyms and Abbreviations

All terms, acronyms and abbreviations which are required to correctly interpret this document are listed in Table 4 Definitions, Table 5 Acronyms and Table 6 Abbreviations respectively.

Table 4 Definitions

|--------|----------------|-----------------|
| ID | Definition | Explanation |
| 1 | | |
| 2 | | |

Table 5 Acronyms

|--------|-------------|-------------------------------------------|
| ID | Acronym | Explanation |
| 1 | BMS | Battery Management System |
| 2 | MIL | Model in the loop |
| 3 | SIL | Software in the loop |
| 4 | HIL | Hardware in the loop |
| 5 | SFMEA | Software Failure Mode and Effect Analysis |
| 6 | TSR | Technical Software Requirement |
| 7 | SSR | Software Safety Requirement |

Table 6 Abbreviations

|--------|------------------|-----------------|
| ID | Abbreviation | Explanation |
| 1 | | |
| 2 | | |

2. Management of Software Verification Activities

This section describes the team organization, schedule, resources, responsibilities, tools, and methodologies to be applied in order to perform the software verification activities for <<PrjName>>.

2.1 Organization

The team organization and individual responsibilities are as defined in Project Plan (Safety Plan).

Table 7 Authorized User

|--------|------------|----------------|-----------|----------|-----------|----------|
| ID | Name | Department | Title | Read | Write | Copy |
| 1 | Engineer 1 | | | ☐ | ☐ | ☐ |
| 2 | Engineer 2 | | | ☐ | ☐ | ☐ |
| 3 | Engineer 3 | | | ☐ | ☐ | ☐ |
| 4 | Engineer 4 | | | ☐ | ☐ | ☐ |
| 5 | ... | | | ☐ | ☐ | ☐ |
| 6 | ... | | | ☐ | ☐ | ☐ |

2.2 Schedule

The project schedule is as defined in Project Plan (Safety Plan).

2.3 Tools and Methodology

This project will adopt the method of developing Software fusing ASPICE, the following is the list of the software tools adopted for successful completion of the project based on model-based development.

Table 8 Software unit test environment

|---------|----------------|------------------------------------------------------------|-------------|---------|
| No. | Tool | Comment | Version | QTY |
| 1 | MATLAB | ... | | |
| 2 | Source Insight | IDE | | |
| 3 | Eclipse | IDE | | |
| 4 | ParaSoft | Do static test and unit dynamic test for hand-coding codes | | |
| 5 | MTest | Do unit dynamic test for Simulink models | | |
| 6 | WindRiver | ... | | |
| 7 | Lauterbach | ... | | |
| 8 | ... | | | |
| 9 | | | | |
| 10 | | | | |

2.4 Evaluation Method

The <<PrjName>> software shall be subjected to different evaluation methods, in accordance with the verification review guidelines. The methods are (example):

  1. Inspection
  2. Review
  3. Walk through
  4. Static code analysis
  5. Dynamic code analysis
  6. SFMEA

3 Software Verification

This section of software verification plan for <<PrjName>> provides the detailed plan for the verification activities throughout the project lifecycle.

3.1 Verification of Software Requirement Phase

3.1.1 Objective

The objective of this phase is to plan for verification of software requirements derived from the system requirements specification.

3.1.2 Inputs

The following documentations shall be provided to execute the verification of Software Requirement:

  1. SRS, incl. SSR(Function Safety)
  2. <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
  3. <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis>

3.1.3 Responsible person

The following person will be in charge of this phase.

|--------|----------|----------------|-----------|
| ID | Name | Department | Title |
| 1 | | | |

3.1.4 Work Products

The following are the deliverables from this sub-phase.

Table 9 Verification Work products of Software (Safety) Requirement Phase

|---------|-------------------------------------------------------------------------|---|
| No. | Work Product | |
| 1 | <XXX-MAN-M3T011_Review Report-XXX-Software Requirement Specification> | |
| 2 | | |
| 3 | | |

3.1.5 Verification Review Methods

The software requirements shall be verified to ensure that:

  1. The software requirements are traceable and consistent with the system requirements
  2. The software requirements are unambiguous, atomic, internally and externally consistent.

The verification review shall be performed using:

  1. <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
  2. <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis>

The following evaluation methods shall be applied for the verification.

Table 10 Methods for the verification of safety requirements

|----|------------------------------|-------|-------|-------|-------|
| Methods || ASIL ||||
| Methods || A | B | C | D |
| 1a | Verification by walk-through | ++ | + | o | o |
| 1b | Verification by inspection | + | ++ | ++ | ++ |
| 1c | Semi-formal verificationa | + | + | ++ | ++ |
| 1d | Formal verificationa | o | + | + | + |
| a Verification can be supported by executable models. ||||||

3.1.6 Environment

All work products of this phase should pass the verification review, all the tools used in verification as below:

Table 11 SSR Verification Environment

|---------|----------|-------------|-------------|---------|
| No. | Tool | Comment | Version | QTY |
| 1 | OFFICE | | | |
| 2 | Doors | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

3.1.7 Entry/Exit Criteria

All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.

3.1.7.1 Entry Criteria

Following are entry criteria for software (safety) requirements:

  1. System Requirements Specification (Incl. Technical Safety Requirements) has been baselined in System Requirements Process.
  2. Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process.
  3. System Design Specification (Incl. Technical Safety Concept) has been baselined in System Design Process.
  4. Hardware Software Interface Specification has been baselined in System Design Process.
  5. Software Requirements Specification Verification Review Checklist should be available.

3.1.7.2 Exit Criteria

Following are exit criteria for software (safety) requirements:

  1. Software Requirements Specification has been approved and baselined.
  2. Software Requirements Specification Verification Review Report has been approved.
  3. Address all issues reported during verification.

3.2 Verification of Software Architecture Design

3.2.1 Objective

The objective of this phase is to plan for verification of software architectural design which is derived from software requirements specification。

3.2.2 Inputs

The following documentations shall be provided to carry out the verification of Software Architectural Design:

  1. SRS, incl. SSR(Function Safety)
  2. <XXX-MAN-M3T010_Checklist-XXX Software Architectural Design Checklist>

3.2.3 Responsible person

The following person will be in charge of this phase.

|--------|----------|----------------|-----------|
| ID | Name | Department | Title |
| 1 | | | |

3.2.4 Work Products

The following are the deliverables from this sub-phase.

Table 12 Verification Work products of Software Architecture Design phase

|---------|--------------------------------------------------------------------|---|
| No. | Work Product | |
| 1 | <XXX-SW-E2T003_XXX-SW Safety Analysis Report> | |
| 2 | <XXX-MAN-M3T011_Review Report-XXX-Software Architectural Design> | |
| 3 | <XXX-SW-E2T002_XXX-Software Architecture Design Specification> | |

3.2.5 Verification Review Methods

The software architectural design verification shall ensure that:

  1. The software architectural design shall comply with the software requirements
  2. The software architectural design shall be developed as a guideline for software unit detailed design.

The verification review shall be performed using:

  1. <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
  2. <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis>

The following evaluation methods shall be applied for the verification.

Table 13 Methods for the verification of safety architectural design

|----|-----------------------------------------------|-------|-------|-------|-------|
| Methods || ASIL ||||
| Methods || A | B | C | D |
| 1a | Walk-through of the designa | ++ | + | o | o |
| 1b | Inspection of the designa | + | ++ | ++ | ++ |
| 1c | Simulation of dynamic behaviour of the design | + | + | + | ++ |
| 1d | Prototype generation | o | o | + | ++ |
| 1e | Formal verification | o | o | + | + |
| 1f | Control flow analysisb | + | + | ++ | ++ |
| 1g | Data flow analysisb | + | + | ++ | ++ |
| 1h | Scheduling analysis | + | + | ++ | ++ |
| a In the case of model-based development, these methods can also be applied to the model. b Control and data flow analysis can be limited to safety-related components and their interfaces. ||||||

3.2.6 Environment

All work products of this phase should pass the verification review, all the tools used in verification as below:

Table 14 Software Architectural Design Verification Environment

|---------|----------|-------------|-------------|---------|
| No. | Tool | Comment | Version | QTY |
| 1 | OFFICE | | | |
| 2 | Doors | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

3.2.7 Entry/Exit Criteria

All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.

3.2.7.1 Entry Criteria

Following are entry criteria for software (safety) requirements:

  1. Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
  2. Configuration Data Specification and Calibration Data Specification have been baselined in Software Requirements Process.
  3. Hardware Software Interface Specification has been baselined in System Design Process.
  4. Software Architectural Design Specification Verification Review Checklist should be available.

3.2.7.2 Exit Criteria

Following are exit criteria for software architecture design:

  1. Software Architectural Design Specification has been approved and baselined.
  2. Software Architectural Design Specification Verification Review Report has been approved.
  3. Address all issues reported during verification.

3.3 Verification of Software Unit Design and Implementation

3.3.1 Objective

The objective of this phase is to plan for verification of software unit design and implementation which is derived from software architectural design.

3.3.2 Inputs

The following documentations shall be provided to carry out the verification of Software Unit Design:

  1. SRS, incl. SSR(Function Safety)
  2. <XXX-SW-E2T002_XXX-Software Architecture Design Specification>
  3. <XXX-SW-G1T001_Guideline for Modelling with Matlab>
  4. <XXX-SW-R1T001_Naming Convention for C-coding>
  5. <XXX-SW-R1T002_Naming Convention for Matlab>
  6. <XXX-SW-E3T002_XXX-SwUnit Detailed Design and Implementation Specification>
  7. <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy>
  8. <XXX-MAN-M3T010_Checklist-XXX Software Unit Design and Implementation>

3.3.3 Responsible person

The following person will be in charge of this phase.

|--------|----------|----------------|-----------|
| ID | Name | Department | Title |
| 1 | | | |

3.3.4 Work Products

The following are the deliverables from this sub-phase.

Table 15 Verification Work products of Software Unit Design and Implementation

|---------|-------------------------------------------------------------------------------|---|
| No. | Work Product | |
| 1 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Design and Implementation > | |
| 2 | | |
| 3 | | |

3.3.5 Verification Review Methods

The verification shall comply with the following:

  1. The software requirements shall be traceable to the allocated software units.
  2. The compliance of implemented model and the source code with the software unit design specification.
  3. The Software Unit Design Specification is developed per <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy>.
  4. The implemented model and source code comply with <XXX-SW-G1T001_Guideline for Modelling with Matlab>.
  5. Static code analysis and semantic analysis is executed on the auto generated source code.

The following evaluation methods shall be applied for the verification review. The verification review shall be performed using Software Design Guidelines and Software Unit Design Specification Checklist.

Table 16 Methods for the Verification of Software Design and Implementation

|----|----------------------------|-------|-------|-------|-------|
| Methods || ASIL ||||
| Methods || A | B | C | D |
| 1a | Walk-through of the design | ++ | + | o | o |
| 1b | Inspection of the design | + | ++ | ++ | ++ |
| 1c | Semi-formal verification | + | + | + | ++ |
| 1e | Formal verification | o | + | + | + |

3.3.6 Environment

All work products of this phase should pass the verification review, all the tools used in verification as below:

Table 17 Software Unit Design Verification Environment

|---------|----------|-------------------------------|-------------|---------|
| No. | Tool | Comment | Version | QTY |
| 1 | IDE | Source Insight, Eclipse, etc. | | |
| 2 | MATLAB | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

3.3.7 Entry/Exit Criteria

All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.

3.3.7.1 Entry Criteria

Following are entry criteria for software (safety) requirements:

  1. Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process
  2. Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
  3. Software Architectural Design Specification has been baselined in Software Architectural Design Process

3.3.7.2 Exit Criteria

Following are exit criteria for Software Unit Design and Implementation:

  1. Software Unit Design Specification has been approved and baselined.
  2. Software Unit Design Specification Verification Review Report has been approved.
  3. Address all issues reported during verification.

3.4 Verification of Software Unit Verification

3.4.1 Objective

The objective of this phase is to plan for software unit verification in order to demonstrate that the software units fulfill the software unit requirements and do not contain undesired functionality.

3.4.2 Test Strategy

Software unit verification strategy is in order to reduce software development risks, time, and cost. In this phase, interfaces tested for proper information flow and all error handling paths should be tested. Software unit tests are expected to against state machines in the software unit design.

3.4.3 Regression Test Strategy

Software unit verification phase shall be executed for the impacted units based on the updated Software Unit Test Specification. Check for defects propagated to other modules by changes made to existing program. Additional test cases focus on software functions likely to be affected by the change. Regression Tests cases focus on the changed software units.

3.4.4 Inputs

The following documentations shall be provided to carry out the verification of Software Unit Verification:

  1. <XXX-SW-E4T001_XXX-SW Unit Verification Strategy>
  2. <XXX-MAN-M3T010_Checklist-XXX Software Unit Verification>
  3. Software Unit Test Case
  4. Software Unit Test Report

3.4.5 Responsible person

The following person will be in charge of this phase.

|--------|----------|----------------|-----------|
| ID | Name | Department | Title |
| 1 | | | |

3.4.6 Work Products

The following are the deliverables from this sub-phase.

Table 18 Verification Work products of Software Unit Verification

|---------|-----------------------------------------------------------------------------------------------------------------------------------------------|---|
| No. | Work Product | |
| 1 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Verification> <XXX-MAN-M3T011_Review Report-XXX-Software Unit Design and Implementation > | |
| 2 | Software Unit Test Report | |
| 3 | | |

3.4.7 Verification Review Methods

The verification review shall be performed to ensure that

  1. There exists at least one test case for each software unit deign requirement.
  2. The tests are traceable to the software unit design requirements.
  3. The tests have been performed in accordance with the methods identified in Project Plan (Safety Plan).
  4. The tests produce the same results and the coverage as reported.
  5. In case of acceptable test failures or incomplete coverage, there exists valid justification recorded.

The following evaluation methods shall be applied for the verification review. The verification review shall be performed using Software Design Guidelines and Software Unit Design Specification Checklist.

Table 19 Methods for the Verification of Software Unit Verification

|---------|------------------------------------|------------------|----------------|
| No. | Inputs for Verification Review | Walk-through | Inspection |
| 1 | Software Unit Test Case | No | Yes |
| 2 | | | |
| 3 | | | |

3.4.8 Test Methods

The methods specified in the following table shall be applied for verification. The verification shall be performed using Software Unit Test Guideline and Software Unit Test Specification Checklist. The detailed requirements refer to <XXX-SW-E4T001_XXX-SW Unit Verification Strategy>.

Table 20 Methods for Software Unit Verification

|----|--------------------------------------------------------------------|-------|-------|-------|-------|
| Method || ASIL ||||
| Method || A | B | C | D |
| 1a | Walk-through | ++ | + | o | o |
| 1b | Pair-programming | + | + | + | + |
| 1c | Inspection | + | ++ | ++ | ++ |
| 1d | Semi-formal verification | + | + | ++ | ++ |
| 1e | Formal verification | o | o | + | + |
| 1f | Control flow analysis | + | + | ++ | ++ |
| 1g | Data flow analysis | + | + | ++ | ++ |
| 1h | Static code analysis | ++ | ++ | ++ | ++ |
| 1i | Static analyses based on abstract interpretation | + | + | + | + |
| 1j | Requirements-based test | ++ | ++ | ++ | ++ |
| 1k | Interface test | ++ | ++ | ++ | ++ |
| 1l | Fault injection test | + | + | + | ++ |
| 1m | Resource usage evaluation | + | + | + | ++ |
| 1n | Back-to-back comparison test between model and code, if applicable | + | + | ++ | ++ |

Table 21 Methods for deriving test cases for software unit testing

|----|-------------------------------------------------|-------|-------|-------|-------|
| Method || ASIL ||||
| Method || A | B | C | D |
| 1a | Analysis of requirements | ++ | ++ | ++ | ++ |
| 1b | Generation and analysis of equivalence classes | + | ++ | ++ | ++ |
| 1c | Analysis of boundary values | + | ++ | ++ | ++ |
| 1d | Error guessing based on knowledge or experience | + | + | + | + |

Table 22 Structural coverage metrZD at the software unit level

|----|----------------------------------------------|-------|-------|-------|-------|
| Method || ASIL ||||
| Method || A | B | C | D |
| 1a | Statement coverage | ++ | ++ | + | + |
| 1b | Branch coverage | + | ++ | ++ | ++ |
| 1c | MC/DC (Modified Condition/Decision Coverage) | + | + | + | ++ |

3.4.9 Environment

All work products of this phase should pass the verification review, all the tools used in verification as below:

Table 23 Software Unit Verification Environment

|---------|----------|-------------|-------------|---------|
| No. | Tool | Comment | Version | QTY |
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |

3.4.10 Entry/Exit Criteria

All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.

3.4.10.1 Entry Criteria

Following are entry criteria for software (safety) requirements:

  1. Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process
  2. Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
  3. Software Architectural Design Specification has been baselined in Software Architectural Design Process

3.4.10.2 Exit Criteria

Following are exit criteria for Software Unit Design and Implementation:

  1. Software Unit Design Specification has been approved and baselined.
  2. Software Unit Design Specification Verification Review Report has been approved.
  3. Address all issues reported during verification.

3.4.11 Software Unit Verification Method

XXX will demand to do the software unit test according to the software unit verification strategy.

The methods for SwUnit verification could be seen as below. XXX will adopt these methods marked with orange.

Table 24 Methods for Software Unit Verification

|---------|--------------------------------------------------------------------|----|----|----|----|------------|
| No. | Methods | Comment |||| Select |
| No. | Methods | A | B | C | D | Select |
| 1a | Walk-through | ++ | + | O | O | R |
| 1b | Pair-programming | + | + | + | + | R |
| 1c | Inspection | + | ++ | ++ | ++ | R |
| 1d | Semi-formal verification | + | + | ++ | ++ | £ |
| 1e | Formal verification | O | O | + | + | £ |
| 1f | Control flow analysis | + | + | ++ | ++ | £ |
| 1g | Data flow analysis | + | + | ++ | ++ | £ |
| 1h | Static code analysis | ++ | ++ | ++ | ++ | R |
| 1i | Static analyses based on abstract interpretation | + | + | + | + | R |
| 1j | Requirements-based test | ++ | ++ | ++ | ++ | R |
| 1k | Interface test | ++ | ++ | ++ | ++ | R |
| 1l | Fault injection test | + | + | + | ++ | R |
| 1m | Resource usage evaluation | + | + | + | ++ | £ |
| 1n | Back-to-back comparison test between model and code, if applicable | + | + | ++ | ++ | £ |
| Refer to ISO 26262-6 § 9.4.2 Table 7, the "check symbol" means will adopt this method. |||||||

未完待续。。。

参考文章

LINK

资源下载：TBD

相关推荐
bitlogic1 个月前
理解 SystemVerilog 中的循环与并发线程
verilog·systemverilog·scope·verification·fpga & design·lifetime·并发线程
老猿讲编程5 个月前
安全关键型嵌入式系统设计模式整理及应用实例
安全·设计模式·iso26262·do178
亚远景aspice5 个月前
ISO 26262标准下的汽车软件架构设计与安全要求
汽车·iso26262
思尔芯S2C6 个月前
What is RISC-V?
fpga开发·soc·risc-v·eda·fpga原型验证·prototyping·verification
亚远景aspice8 个月前
探究项目未能获得ASPICE 1、2级能力的原因及改进策略
iso26262·aspice
亚远景aspice8 个月前
ISO 26262在汽车软件开发中的作用
iso26262
亚远景aspice8 个月前
汽车软件开发：ASPICE与ISO26262标准下的质量管理与控制实践
iso26262·aspice
亚远景aspice10 个月前
功能安全如何在公司顺利开展？-亚远景科技
科技·汽车·iso26262·软件研发管理
亚远景aspice1 年前
亚远景科技-结合ASPICE和ISO26262标准谈谈汽车软件开发中的质量管理与控制
科技·汽车·iso26262·aspice4.0·软件研发管理
热门推荐
01RAG 实践- Ollama+RagFlow 部署本地知识库02如何在WPS和Word/Excel中直接使用DeepSeek功能03DeepSeek各版本说明与优缺点分析04本地化部署AI知识库：基于Ollama+DeepSeek+AnythingLLM保姆级教程05从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑06本地部署DeepSeek教程（Mac版本）07避坑！用Docker搞定PHP开发环境搭建（Mac、Docker、Nginx、PHP-FPM、XDebug、PHPStorm、VSCode）08命令行方式将mysql数据库迁移到达梦数据库（全步骤）09DeepSeek R1本地化部署 Ollama + Chatbox 打造最强 AI 工具102 本地部署DeepSeek模型构建本地知识库+联网搜索详细步骤