RTEMS Software Engineering (7.491f6c8)

Contents

RTEMS Software Engineering (7.491f6c8)#

This document is available under the Creative Commons Attribution-ShareAlike 4.0 International Public License.

The authors have used their best efforts in preparing this material. These efforts include the development, research, and testing of the theories and programs to determine their effectiveness. No warranty of any kind, expressed or implied, with regard to the software or the material contained in this document is provided. No liability arising out of the application or use of any product described in this document is assumed. The authors reserve the right to revise this material and to make changes from time to time in the content hereof without obligation to notify anyone of such revision or changes.

The RTEMS Project is hosted at https://www.rtems.org. Any inquiries concerning RTEMS, its related support components, or its documentation should be directed to the RTEMS Project community.

RTEMS Online Resources

1. Preface#

This manual aims to guide the development of RTEMS itself. You should read this document if you want to participate in the development of RTEMS. Users of RTEMS may find background information in this manual. Please refer to the RTEMS User Manual and RTEMS Classic API Guide if you want to know how the RTEMS development environment is set up and how you can develop applications using RTEMS.

2. RTEMS Project Mission Statement#

RTEMS development done under the umbrella of the RTEMS Project aims to provide a free and open real-time operating system targeted towards deeply embedded systems which is competitive with proprietary products. The RTEMS Project encourages the support and use of standard APIs in order to promote application portability and ease porting other packages to the RTEMS environment.

The RTEMS development effort uses an open development environment in which all users collaborate to improve RTEMS. The RTEMS cross development tool suite is based upon the free GNU tools and the open source standard C library newlib. RTEMS supports many host platforms and target architectures.

2.1. Free Software Project#

The free software goals of the project are:

  • RTEMS and supporting components are available under various free licenses with copyrights being held by individual authors.

  • All software which executes on the target will not place undue restrictions on embedded applications. See also Licensing Requirements.

  • Patches must be legally acceptable for inclusion into the RTEMS Project or the specific project being used.

2.2. Design and Development Goals#

  • Source based development with all users building from source

  • Any suitable host should be supported

  • Open testing, tests and test results

  • Ports to new architectures and CPU models

  • Addition of Board Support Packages for available hardware

  • Improved runtime libraries

  • Faster debug cycle

  • Various other infrastructure improvements

2.3. Open Development Environment#

  • Encourage cooperation and communication between developers

  • Work more closely with “consumers”

  • Code available to everyone at any time, and everyone is welcome to participate in development

  • Patches will be considered equally based on their technical merits

  • All individuals and companies are welcome to contribute as long as they accept the ground rules

  • Open mailing lists

  • Developer friendly tools and procedures with a focus on keeping them current

  • Conflicts of interest exist for many RTEMS developers. The developers contributing to the RTEMS Project must put the interests of the RTEMS Project first.

3. RTEMS Stakeholders#

You are a potential RTEMS stakeholder. RTEMS is a community based free and open source project. All users are treated as stakeholders. It is hoped that as stakeholders, users will contribute to the project, sponsor core developers, and help fund the infrastructure required to host and manage the project. Please have a look at the Support and Contributing chapter of the RTEMS User Manual.

4. Introduction to Pre-Qualification#

RTEMS has a long history of being used to support critical applications. In some of these application domains, there are standards (e.g., DO-178C, NPR 7150.2) which define the expectations for the processes used to develop software and the associated artifacts. These standards typically do not specify software functionality but address topics like requirements definition, traceability, having a documented change process, coding style, testing requirements, and a user’s manual. During system test, these standards call for a review - usually by an independent entity - that the standard has been adhered to. These reviews cover a broad variety of topics and activities, but the process is generally referred to as qualification, verification, or auditing against the specific standard in use. The RTEMS Project will use the term “qualification” independent of the standard.

The goal of the RTEMS Qualification Project is to make RTEMS easier to review regardless of the standard chosen. Quite specifically, the RTEMS Qualification effort will NOT produce a directly qualified product or artifacts in the format dictated by a specific organization or standard. The goal is to make RTEMS itself, documentation, testing infrastructure, etc. more closely align with the information requirements of these high integrity qualification standards. In addition to improving the items that a mature, high quality open source project will have, there are additional artifacts needed for a qualification effort that no known open source project possesses. Specifically, requirements and the associated traceability to source code, tests, and documentation are needed.

The RTEMS Qualification Project is technically “pre-qualification.” True qualification must be performed on the project’s target hardware in a system context. The FAA has provided guidance for Reusable Software Components (FAA-AC20-148) and this effort should follow that guidance. The open RTEMS Project, with the assistance of domain experts, will possess and maintain the master technical information needed in a qualification effort. Consultants will provide the services required to tailor the master information, perform testing on specific system hardware, and to guide end users in using the master technical data in the context of a particular standard.

The RTEMS Qualification Project will broadly address two areas. The first area is suggesting areas of improvement for automated project infrastructure and the master technical data that has traditionally been provided by the RTEMS Project. For example, the RTEMS Qualification could suggest specific improvements to code coverage reports. The teams focused on qualification should be able to provide resources for improving the automated project infrastructure and master technical data for RTEMS. The term “resources” is often used by open source projects to refer to volunteer code contributions or funding. Although code contributions in this area are important and always welcome, funding is also important. At a minimum, ongoing funding is needed for maintenance and upgrades of the RTEMS Project server infrastructure, addition of services to those servers, and core contributors to review submissions

The second area is the creation and maintenance of master technical data that has traditionally not been owned or maintained by the RTEMS Project. The most obvious example of this is a requirements set with proper infrastructure for tracing requirements through code to test and documentation. It is expected that these will be maintained by the RTEMS Qualification Project. They will be evaluated for adoption by the main RTEMS Project but the additional maintenance burden imposed will be a strong factor in this consideration. It behooves the RTEMS Qualification Project to limit dependence on manual checks and ensure that automation and ongoing support for that automation is contributed to the RTEMS Project.

It is expected that the RTEMS Qualification Project will create and maintain maps from the RTEMS master technical data to the various qualification standards. It will maintain “scorecards” which identify how the RTEMS Project is currently doing when reviewed per each standard. These will be maintained in the open as community resources which will guide the community in improving its infrastructure.

4.1. Stakeholder Involvement#

Qualification of RTEMS is a specialized activity and only specific users of RTEMS will complete a formal qualification activity. The RTEMS Project cannot self-fund this entire activity and requires stakeholders to invest on an ongoing basis to ensure that any investment they make is maintained and viable in the long-term. The RTEMS core developers view steady support of the qualification effort as necessary to continue to lower the overall costs of qualifying RTEMS.

5. Software Requirements Engineering#

Software engineering standards for critical software such as ECSS-E-ST-40C demand that software requirements for a software product are collected in a software requirements specification (technical specification in ECSS-E-ST-40C terms). They are usually derived from system requirements (requirements baseline in ECSS-E-ST-40C terms). RTEMS is designed as a reusable software product which can be utilized by application designers to ease the development of their applications. The requirements of the end system (system requirements) using RTEMS are only known to the application designer. RTEMS itself is developed by the RTEMS maintainers and they do not know the requirements of a particular end system in general. RTEMS is designed as a real-time operating system to meet typical system requirements for a wide range of applications. Its suitability for a particular application must be determined by the application designer based on the technical specification provided by RTEMS accompanied with performance data for a particular target platform.

Currently, no technical specification of RTEMS exists in the form of a dedicated document. Since the beginning of the RTEMS evolution in the late 1980s it was developed iteratively. It was never developed in a waterfall model. During initial development the RTEID [Mot88] and later the ORKID [VIT90] draft specifications were used as requirements. These were evolving during the development and an iterative approach was followed often using simple algorithms and coming back to optimise. In 1993 and 1994 a subset of pthreads sufficient to support GNAT was added as requirements. At this time the Ada tasking was defined, however, not implemented in GNAT, so this involved guessing during the development. Later some adjustments were made when Ada tasking was actually implemented. So, it was consciously iterative with the specifications evolving and feedback from performance analysis. Benchmarks published from other real time operating systems were used for comparison. Optimizations were carried out until the results were comparable. Development was done with distinct contractual phases and tasks for development, optimization, and the addition of priority inheritance and rate monotonic scheduling. The pthreads requirement has grown to be as much POSIX as possible.

Portability from FreeBSD to use its network stack, USB stack, SD/MMC card stack and device drivers resulted in another set of requirements. The addition of support for symmetric multiprocessing (SMP) was a huge driver for change. It was developed step by step and sponsored by several independent users with completely different applications and target platforms in mind. The high performance OpenMP support introduced the Futex as a new synchronization primitive.

We have to put in some effort first into the reconstruction of software requirements through reverse engineering using the RTEMS documentation, test cases, sources, standard references, mailing list archives, etc. as input. Writing a technical specification for the complete RTEMS code base is probably a job of several person-years. We have to get started with a moderate feature set (e.g. subset of the Classic API) and extend it based on user demands step by step.

The development of the technical specification will take place in two phases. The first phase tries to establish an initial technical specification for an initial feature set. This technical specification will be integrated into RTEMS as a big chunk. In the second phase the technical specification is modified through arranged procedures. There will be procedures

  • to modify existing requirements,

  • add new requirements, and

  • mark requirements as obsolete.

All procedures should be based on a peer review principles.

5.1. Requirements for Requirements#

5.1.1. Identification#

Each requirement shall have a unique identifier (UID). The question is in which scope should it be unique? Ideally, it should be universally unique. Therefore all UIDs used to link one specification item to another should use relative UIDs. This ensures that the RTEMS requirements can be referenced easily in larger systems though a system-specific prefix. The standard ECSS-E-ST-10-06C recommends in section 8.2.6 that the identifier should reflect the type of the requirement and the life profile situation. Other standards may have other recommendations. To avoid a bias of RTEMS in the direction of ECSS, this recommendation will not be followed.

The absolute UID of a specification item (for example a requirement) is defined by a leading / and the path of directories from the specification base directory to the file of the item separated by / characters and the file name without the .yml extension. For example, a specification item contained in the file build/cpukit/librtemscpu.yml inside a spec directory has the absolute UID of /build/cpukit/librtemscpu.

The relative UID to a specification item is defined by the path of directories from the file containing the source specification item to the file of the destination item separated by / characters and the file name of the destination item without the .yml extension. For example the relative UID from /build/bsps/sparc/leon3/grp to /build/bsps/bspopts is ../../bspopts.

Basically, the valid characters of an UID are determined by the file system storing the item files. By convention, UID characters shall be restricted to the following set defined by the regular expression [a-zA-Z0-9_-]+. Use - as a separator inside an UID part.

In documents the URL-like prefix spec: shall be used to indicated specification item UIDs.

The UID scheme for RTEMS requirements shall be component based. For example, the UID spec:/classic/task/create-err-invaddr may specify that the rtems_task_create() directive shall return a status of RTEMS_INVALID_ADDRESS if the id parameter is NULL.

A initial requirement item hierarchy could be this:

  • build (building RTEMS BSPs and libraries)

  • acfg (application configuration groups)

    • opt (application configuration options)

  • classic

    • task

      • create-* (requirements for rtems_task_create())

      • delete-* (requirements for rtems_task_delete())

      • exit-* (requirements for rtems_task_exit())

      • getaff-* (requirements for rtems_task_get_affinity())

      • getpri-* (requirements for rtems_task_get_priority())

      • getsched-* (requirements for rtems_task_get_scheduler())

      • ident-* (requirements for rtems_task_ident())

      • issusp-* (requirements for rtems_task_is_suspended())

      • iter-* (requirements for rtems_task_iterate())

      • mode-* (requirements for rtems_task_mode())

      • restart-* (requirements for rtems_task_restart())

      • resume* (requirements for rtems_task_resume())

      • self* (requirements for rtems_task_self())

      • setaff-* (requirements for rtems_task_set_affinity())

      • setpri-* (requirements for rtems_task_set_priority())

      • setsched* (requirements for rtems_task_set_scheduler())

      • start-* (requirements for rtems_task_start())

      • susp-* (requirements for rtems_task_suspend())

      • wkafter-* (requirements for rtems_task_wake_after())

      • wkwhen-* (requirements for rtems_task_wake_when())

    • sema

  • posix

A more detailed naming scheme and guidelines should be established. We have to find the right balance between the length of UIDs and self-descriptive UIDs. A clear scheme for all Classic API managers may help to keep the UIDs short and descriptive.

The specification of the validation of requirements should be maintained also by specification items. For each requirement directory there should be a validation subdirectory named test, e.g. spec/classic/task/test. A test specification directory may contain also validations by analysis, by inspection, and by design, see Requirement Validation.

5.1.2. Level of Requirements#

The level of a requirement shall be expressed with one of the verbal forms listed below and nothing else. The level of requirements are derived from RFC 2119 [Bra97] and ECSS-E-ST-10-06C [ECS09].

5.1.2.1. Absolute Requirements#

Absolute requirements shall be expressed with the verbal form shall and no other terms.

5.1.2.2. Absolute Prohibitions#

Absolute prohibitions shall be expressed with the verbal form shall not and no other terms.

Warning

Absolute prohibitions may be difficult to validate. They should not be used.

5.1.2.3. Recommendations#

Recommendations shall be expressed with the verbal forms should and should not and no other terms with guidance from RFC 2119:

SHOULD This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5.1.2.4. Permissions#

Permissions shall be expressed with the verbal form may and no other terms with guidance from RFC 2119:

MAY This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

5.1.2.5. Possibilities and Capabilities#

Possibilities and capabilities shall be expressed with the verbal form can and no other terms.

5.1.3. Syntax#

Use the Easy Approach to Requirements Syntax (EARS) to formulate requirements. A recommended reading list to get familiar with this approach is [MWHN09], [MW10], [MWGU16], and Alisair Mavin’s web site. The patterns are:

  • Ubiquitous

    The <system name> shall <system response>.

  • Event-driven

    When <trigger>, the <system name> shall <system response>.

  • State-driven

    While <pre-condition>, the <system name> shall <system response>.

  • Unwanted behaviour

    If <trigger>, then the <system name> shall <system response>.

  • Optional

    Where <feature is included>, the <system name> shall <system response>.

  • Complex

    Where <feature 0 is included>, where <feature 1 is included>, …, where <feature n is included>, while <pre-condition 0>, while <pre-condition 1>, …, while <pre-condition m>, when <trigger>, the <system name> shall <system response>.

    Where <feature 0 is included>, where <feature 1 is included>, …, where <feature n is included>, while <pre-condition 0>, while <pre-condition 1>, …, while <pre-condition m>, if <trigger>, then the <system name> shall <system response>.

The optional pattern should be only used for application configuration options. The goal is to use the enabled-by attribute to enable or disable requirements based on configuration parameters that define the RTEMS artefacts used to build an application executable (header files, libraries, linker command files). Such configuration parameters are for example the architecture, the platform, CPU port options, and build configuration options (e.g. uniprocessor vs. SMP).

5.1.4. Wording Restrictions#

To prevent the expression of imprecise requirements, the following terms shall not be used in requirement formulations:

  • “acceptable”

  • “adequate”

  • “almost always”

  • “and/or”

  • “appropriate”

  • “approximately”

  • “as far as possible”

  • “as much as practicable”

  • “best”

  • “best possible”

  • “easy”

  • “efficient”

  • “e.g.”

  • “enable”

  • “enough”

  • “etc.”

  • “few”

  • “first rate”

  • “flexible”

  • “generally”

  • “goal”

  • “graceful”

  • “great”

  • “greatest”

  • “ideally”

  • “i.e.”

  • “if possible”

  • “in most cases”

  • “large”

  • “many”

  • “maximize”

  • “minimize”

  • “most”

  • “multiple”

  • “necessary”

  • “numerous”

  • “optimize”

  • “ought to”

  • “probably”

  • “quick”

  • “rapid”

  • “reasonably”

  • “relevant”

  • “robust”

  • “satisfactory”

  • “several”

  • “shall be included but not limited to”

  • “simple”

  • “small”

  • “some”

  • “state-of-the-art”.

  • “sufficient”

  • “suitable”

  • “support”

  • “systematically”

  • “transparent”

  • “typical”

  • “user-friendly”

  • “usually”

  • “versatile”

  • “when necessary”

For guidelines to avoid these terms see Table 11-2, “Some ambiguous terms to avoid in requirements” in [WB13]. There should be some means to enforce that these terms are not used, e.g. through a client-side pre-commit Git hook, a server-side pre-receive Git hook, or some scripts run by special build commands.

5.1.5. Separate Requirements#

Requirements shall be stated separately. A bad example is:

spec:/classic/task/create

The task create directive shall evaluate the parameters, allocate a task object and initialize it.

To make this a better example, it should be split into separate requirements:

spec:/classic/task/create

When the task create directive is called with valid parameters and a free task object exists, the task create directive shall assign the identifier of an initialized task object to the id parameter and return the RTEMS_SUCCESSFUL status.

spec:/classic/task/create-err-toomany

If no free task objects exists, the task create directive shall return the RTEMS_TOO_MANY status.

spec:/classic/task/create-err-invaddr

If the id parameter is NULL, the task create directive shall return the RTEMS_INVALID_ADDRESS status.

spec:/classic/task/create-err-invname

If the name parameter is invalid, the task create directive shall return the RTEMS_INVALID_NAME status.

5.1.6. Conflict Free Requirements#

Requirements shall not be in conflict with each other inside a specification. A bad example is:

spec:/classic/sema/mtx-obtain-wait

When a mutex is not available, the mutex obtain directive shall enqueue the calling thread on the wait queue of the mutex.

spec:/classic/sema/mtx-obtain-err-unsat

If a mutex is not available, the mutex obtain directive shall return the RTEMS_UNSATISFIED status.

To resolve this conflict, a condition may be added:

spec:/classic/sema/mtx-obtain-wait

When a mutex is not available and the RTEMS_WAIT option is set, the mutex obtain directive shall enqueue the calling thread on the wait queue of the mutex.

spec:/classic/sema/mtx-obtain-err-unsat

If a mutex is not available, when the RTEMS_WAIT option is not set, the mutex obtain directive shall return the RTEMS_UNSATISFIED status.

5.1.7. Use of Project-Specific Terms and Abbreviations#

All project-specific terms and abbreviations used to formulate requirements shall be defined in the project glossary.

5.1.8. Justification of Requirements#

Each requirement shall have a rationale or justification recorded in a dedicated section of the requirement file. See rationale attribute for Specification Items.

5.1.9. Requirement Validation#

The validation of each Requirement Item Type item shall be accomplished by one or more specification items of the types Test Case Item Type or Requirement Validation Item Type through a link from the validation item to the requirement item with the Requirement Validation Link Role.

Validation by test is strongly recommended. The choice of any other validation method shall be strongly justified. The requirements author is obligated to provide the means to validate the requirement with detailed instructions.

5.1.10. Resources and Performance#

Normally, resource and performance requirements are formulated like this:

  • The resource U shall need less than V storage units.

  • The operation Y shall complete within X time units.

Such statements are difficult to make for a software product like RTEMS which runs on many different target platforms in various configurations. So, the performance requirements of RTEMS shall be stated in terms of benchmarks. The benchmarks are run on the project-specific target platform and configuration. The results obtained by the benchmark runs are reported in a human readable presentation. The application designer can then use the benchmark results to determine if its system performance requirements are met. The benchmarks shall be executed under different environment conditions, e.g. varying cache states (dirty, empty, valid) and system bus load generated by other processors. The application designer shall have the ability to add additional environment conditions, e.g. system bus load by DMA engines or different system bus arbitration schemes.

To catch resource and performance regressions via test suite runs there shall be a means to specify threshold values for the measured quantities. The threshold values should be provided for each validation platform. How this can be done and if the threshold values are maintained by the RTEMS Project is subject to discussion.

5.2. Specification Items#

5.2.1. Specification Item Hierarchy#

The specification item types have the following hierarchy:

5.2.2. Specification Item Types#

5.2.2.1. Root Item Type#

The technical specification of RTEMS will contain for example requirements, specializations of requirements, interface specifications, test suites, test cases, and requirement validations. These things will be called specification items or just items if it is clear from the context.

The specification items are stored in files in YAML format with a defined set of key-value pairs called attributes. Each attribute key name shall be a Name. In particular, key names which begin with an underscore (_) are reserved for internal use in tools.

This is the root specification item type. All explicit attributes shall be specified. The explicit attributes for this type are:

SPDX-License-Identifier

The attribute value shall be a SPDX License Identifier. It shall be the license of the item.

copyrights

The attribute value shall be a list. Each list element shall be a Copyright. It shall be the list of copyright statements of the item.

enabled-by

The attribute value shall be an Enabled-By Expression. It shall define the conditions under which the item is enabled.

links

The attribute value shall be a list. Each list element shall be a Link.

type

The attribute value shall be a Name. It shall be the item type. The selection of types and the level of detail depends on a particular standard and product model. We need enough flexibility to be in line with ECSS-E-ST-10-06 and possible future applications of other standards. The item type may be refined further with additional type-specific subtypes.

This type is refined by the following types:

5.2.2.2. Build Item Type#

This type refines the Root Item Type through the type attribute if the value is build. This set of attributes specifies a build item. Only the build-type attribute is mandatory. The explicit attributes for this type are:

build-type

The attribute value shall be a Name. It shall be the build item type.

extra-files

The attribute value shall be a list of strings. If the value is present, it shall be the list of extra files associated with the item.

This type is refined by the following types:

5.2.2.3. Build Ada Test Program Item Type#

This type refines the Build Item Type through the build-type attribute if the value is ada-test-program. This set of attributes specifies an Ada test program executable to build. Test programs may use additional objects provided by Build Objects Item Type items. Test programs have an implicit enabled-by attribute value which is controlled by the option action set-test-state. If the test state is set to exclude, then the test program is not built. All explicit attributes shall be specified. The explicit attributes for this type are:

ada-main

The attribute value shall be a string. It shall be the path to the Ada main body file.

ada-object-directory

The attribute value shall be a string. It shall be the path to the Ada object directory (-D option value for gnatmake).

adaflags

The attribute value shall be a list of strings. It shall be a list of options for the Ada compiler.

adaincludes

The attribute value shall be a list of strings. It shall be a list of Ada include paths.

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

ldflags

The attribute value shall be a list. Each list element shall be a Build Linker Option.

source

The attribute value shall be a list. Each list element shall be a Build Source.

stlib

The attribute value shall be a list. Each list element shall be a Build Link Static Library Directive.

target

The attribute value shall be a Build Target.

use-after

The attribute value shall be a list. Each list element shall be a Build Use After Directive.

use-before

The attribute value shall be a list. Each list element shall be a Build Use Before Directive.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
ada-main: testsuites/ada/samples/hello/hello.adb
ada-object-directory: testsuites/ada/samples/hello
adaflags: []
adaincludes:
- cpukit/include/adainclude
- testsuites/ada/support
build-type: ada-test-program
cflags: []
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
cxxflags: []
enabled-by: true
includes: []
ldflags: []
links: []
source:
- testsuites/ada/samples/hello/init.c
stlib: []
target: testsuites/ada/ada_hello.exe
type: build
use-after: []
use-before: []
5.2.2.4. Build BSP Item Type#

This type refines the Build Item Type through the build-type attribute if the value is bsp. This set of attributes specifies a base BSP variant to build. All explicit attributes shall be specified. The explicit attributes for this type are:

arch

The attribute value shall be a string. It shall be the target architecture of the BSP.

bsp

The attribute value shall be a string. It shall be the base BSP variant name.

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

family

The attribute value shall be a string. It shall be the BSP family name. The name shall be the last directory of the path to the BSP sources.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

install

The attribute value shall be a list. Each list element shall be a Build Install Directive.

source

The attribute value shall be a list. Each list element shall be a Build Source.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
arch: myarch
bsp: mybsp
build-type: bsp
cflags: []
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
enabled-by: true
family: mybsp
includes: []
install:
- destination: ${BSP_INCLUDEDIR}
  source:
  - bsps/myarch/mybsp/include/bsp.h
  - bsps/myarch/mybsp/include/tm27.h
- destination: ${BSP_INCLUDEDIR}/bsp
  source:
  - bsps/myarch/mybsp/include/bsp/irq.h
- destination: ${BSP_LIBDIR}
  source:
  - bsps/myarch/mybsp/start/linkcmds
links:
- role: build-dependency
  uid: ../../obj
- role: build-dependency
  uid: ../../opto2
- role: build-dependency
  uid: abi
- role: build-dependency
  uid: obj
- role: build-dependency
  uid: ../start
- role: build-dependency
  uid: ../../bspopts
source:
- bsps/myarch/mybsp/start/bspstart.c
type: build
5.2.2.5. Build Configuration File Item Type#

This type refines the Build Item Type through the build-type attribute if the value is config-file. This set of attributes specifies a configuration file placed in the build tree. The configuration file is generated during the configure command execution and is placed in the build tree. All explicit attributes shall be specified. The explicit attributes for this type are:

content

The attribute value shall be a string. It shall be the content of the configuration file. A ${VARIABLE} substitution is performed during the configure command execution using the variables of the configuration set. Use $$ for a plain $ character. To have all variables from sibling items available for substitution it is recommended to link them in the proper order.

install-path

The attribute value shall be a Build Install Path.

target

The attribute value shall be a Build Target.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: config-file
content: |
  # ...
  Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
  # ...
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
enabled-by: true
install-path: ${PREFIX}/lib/pkgconfig
links: []
target: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}.pc
type: build
5.2.2.6. Build Configuration Header Item Type#

This type refines the Build Item Type through the build-type attribute if the value is config-header. This set of attributes specifies configuration header file. The configuration header file is generated during configure command execution and is placed in the build tree. All collected configuration defines are written to the configuration header file during the configure command execution. To have all configuration defines from sibling items available it is recommended to link them in the proper order. All explicit attributes shall be specified. The explicit attributes for this type are:

guard

The attribute value shall be a string. It shall be the header guard define.

include-headers

The attribute value shall be a list of strings. It shall be a list of header files to include via #include <...>.

install-path

The attribute value shall be a Build Install Path.

target

The attribute value shall be a Build Target.

5.2.2.7. Build Group Item Type#

This type refines the Build Item Type through the build-type attribute if the value is group. This set of attributes provides a means to aggregate other build items and modify the build item context which is used by referenced build items. The includes, ldflags, objects, and use variables of the build item context are updated by the corresponding attributes of the build group. All explicit attributes shall be specified. The explicit attributes for this type are:

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

install

The attribute value shall be a list. Each list element shall be a Build Install Directive.

ldflags

The attribute value shall be a list of strings. It shall be a list of options for the linker. They are used to link executables referenced by this item.

use-after

The attribute value shall be a list. Each list element shall be a Build Use After Directive.

use-before

The attribute value shall be a list. Each list element shall be a Build Use Before Directive.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: group
cflags: []
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
cxxflags: []
enabled-by:
- BUILD_TESTS
- BUILD_SAMPLES
includes:
- testsuites/support/include
install: []
ldflags:
- -Wl,--wrap=printf
- -Wl,--wrap=puts
links:
- role: build-dependency
  uid: ticker
type: build
use-after: []
use-before:
- rtemstest
5.2.2.8. Build Library Item Type#

This type refines the Build Item Type through the build-type attribute if the value is library. This set of attributes specifies a static library. Library items may use additional objects provided by Build Objects Item Type items through the build dependency links of the item. All explicit attributes shall be specified. The explicit attributes for this type are:

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

install

The attribute value shall be a list. Each list element shall be a Build Install Directive.

install-path

The attribute value shall be a Build Install Path.

source

The attribute value shall be a list. Each list element shall be a Build Source.

target

The attribute value shall be a Build Target. It shall be the name of the static library, e.g. z for libz.a.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: library
cflags:
- -Wno-pointer-sign
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
cxxflags: []
enabled-by: true
includes:
- cpukit/libfs/src/jffs2/include
install:
- destination: ${BSP_INCLUDEDIR}/rtems
  source:
  - cpukit/include/rtems/jffs2.h
install-path: ${BSP_LIBDIR}
links: []
source:
- cpukit/libfs/src/jffs2/src/build.c
target: jffs2
type: build
5.2.2.9. Build Objects Item Type#

This type refines the Build Item Type through the build-type attribute if the value is objects. This set of attributes specifies a set of object files used to build static libraries or test programs. Objects Items must not be included on multiple paths through the build dependency graph with identical build options. Violating this can cause race conditions in the build system due to duplicate installs and multiple instances of build tasks. All explicit attributes shall be specified. The explicit attributes for this type are:

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

install

The attribute value shall be a list. Each list element shall be a Build Install Directive.

source

The attribute value shall be a list. Each list element shall be a Build Source.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: objects
cflags: []
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
cxxflags: []
enabled-by: true
includes: []
install:
- destination: ${BSP_INCLUDEDIR}/bsp
  source:
  - bsps/include/bsp/bootcard.h
  - bsps/include/bsp/default-initial-extension.h
  - bsps/include/bsp/fatal.h
links: []
source:
- bsps/shared/start/bootcard.c
- bsps/shared/rtems-version.c
type: build
5.2.2.10. Build Option Item Type#

This type refines the Build Item Type through the build-type attribute if the value is option. This set of attributes specifies a build option. The following explicit attributes are mandatory:

  • actions

  • default

  • description

The explicit attributes for this type are:

actions

The attribute value shall be a list. Each list element shall be a Build Option Action. Each action operates on the action value handed over by a previous action and action-specific attribute values. The actions pass the processed action value to the next action in the list. The first action starts with an action value of None. The actions are carried out during the configure command execution.

default

The attribute value shall be a list. Each list element shall be a Build Option Value. It shall be the list of default values of the option. When a default value is needed, the first value on the list which is enabled according to the enabled set is chosen. If no value is enabled, then the default value is null.

description

The attribute value shall be an optional string. It shall be the description of the option.

format

The attribute value shall be an optional string. It shall be a Python format string, for example '{}' or '{:#010x}'.

name

The attribute value shall be a Build Option Name.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
- define: null
build-type: option
copyrights:
- Copyright (C) 2020, 2022 embedded brains GmbH & Co. KG
default:
- enabled-by:
  - bsps/powerpc/motorola_powerpc
  - m68k/m5484FireEngine
  - powerpc/hsc_cm01
  value: 9600
- enabled-by: m68k/COBRA5475
  value: 19200
- enabled-by: true
  value: 115200
description: |
  Default baud for console and other serial devices.
enabled-by: true
format: '{}'
links: []
name: BSP_CONSOLE_BAUD
type: build
5.2.2.11. Build Script Item Type#

This type refines the Build Item Type through the build-type attribute if the value is script. This set of attributes specifies a build script. The optional attributes may be required by commands executed through the scripts. The following explicit attributes are mandatory:

  • do-build

  • do-configure

  • prepare-build

  • prepare-configure

The explicit attributes for this type are:

asflags

The attribute value shall be a list. Each list element shall be a Build Assembler Option.

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

do-build

The attribute value shall be an optional string. If this script shall execute, then it shall be Python code which is executed via exec() in the context of the do_build() method of the wscript. A local variable bld is available with the waf build context. A local variable bic is available with the build item context.

do-configure

The attribute value shall be an optional string. If this script shall execute, then it shall be Python code which is executed via exec() in the context of the do_configure() method of the wscript. A local variable conf is available with the waf configuration context. A local variable cic is available with the configuration item context.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

ldflags

The attribute value shall be a list. Each list element shall be a Build Linker Option.

prepare-build

The attribute value shall be an optional string. If this script shall execute, then it shall be Python code which is executed via exec() in the context of the prepare_build() method of the wscript. A local variable bld is available with the waf build context. A local variable bic is available with the build item context.

prepare-configure

The attribute value shall be an optional string. If this script shall execute, then it shall be Python code which is executed via exec() in the context of the prepare_configure() method of the wscript. A local variable conf is available with the waf configuration context. A local variable cic is available with the configuration item context.

stlib

The attribute value shall be a list. Each list element shall be a Build Link Static Library Directive.

target

The attribute value shall be a Build Target.

use-after

The attribute value shall be a list. Each list element shall be a Build Use After Directive.

use-before

The attribute value shall be a list. Each list element shall be a Build Use Before Directive.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: script
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
default: null
default-by-variant: []
do-build: |
  bld.install_as(
      "${BSP_LIBDIR}/linkcmds",
      "bsps/" + bld.env.ARCH + "/" + bld.env.BSP_FAMILY +
      "/start/linkcmds." + bld.env.BSP_BASE
  )
do-configure: |
  conf.env.append_value(
      "LINKFLAGS",
      ["-qnolinkcmds", "-T", "linkcmds." + conf.env.BSP_BASE]
  )
enabled-by: true
links: []
prepare-build: null
prepare-configure: null
type: build
5.2.2.12. Build Start File Item Type#

This type refines the Build Item Type through the build-type attribute if the value is start-file. This set of attributes specifies a start file to build. A start file is used to link an executable. All explicit attributes shall be specified. The explicit attributes for this type are:

asflags

The attribute value shall be a list. Each list element shall be a Build Assembler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

install-path

The attribute value shall be a Build Install Path.

source

The attribute value shall be a list. Each list element shall be a Build Source.

target

The attribute value shall be a Build Target.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
asflags: []
build-type: start-file
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
enabled-by: true
includes: []
install-path: ${BSP_LIBDIR}
links: []
source:
- bsps/sparc/shared/start/start.S
target: start.o
type: build
5.2.2.13. Build Test Program Item Type#

This type refines the Build Item Type through the build-type attribute if the value is test-program. This set of attributes specifies a test program executable to build. Test programs may use additional objects provided by Build Objects Item Type items. Test programs have an implicit enabled-by attribute value which is controlled by the option action set-test-state. If the test state is set to exclude, then the test program is not built. All explicit attributes shall be specified. The explicit attributes for this type are:

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

cppflags

The attribute value shall be a list. Each list element shall be a Build C Preprocessor Option.

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

features

The attribute value shall be a string. It shall be the waf build features for this test program.

includes

The attribute value shall be a list. Each list element shall be a Build Include Path.

ldflags

The attribute value shall be a list. Each list element shall be a Build Linker Option.

source

The attribute value shall be a list. Each list element shall be a Build Source.

stlib

The attribute value shall be a list. Each list element shall be a Build Link Static Library Directive.

target

The attribute value shall be a Build Target.

use-after

The attribute value shall be a list. Each list element shall be a Build Use After Directive.

use-before

The attribute value shall be a list. Each list element shall be a Build Use Before Directive.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: test-program
cflags: []
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
cppflags: []
cxxflags: []
enabled-by: true
features: c cprogram
includes: []
ldflags: []
links: []
source:
- testsuites/samples/ticker/init.c
- testsuites/samples/ticker/tasks.c
stlib: []
target: testsuites/samples/ticker.exe
type: build
use-after: []
use-before: []
5.2.2.14. Constraint Item Type#

This type refines the Root Item Type through the type attribute if the value is constraint. This set of attributes specifies a constraint. All explicit attributes shall be specified. The explicit attributes for this type are:

rationale

The attribute value shall be an optional string. If the value is present, then it shall state the rationale or justification of the constraint.

text

The attribute value shall be a Requirement Text. It shall state the constraint.

5.2.2.15. Glossary Item Type#

This type refines the Root Item Type through the type attribute if the value is glossary. This set of attributes specifies a glossary item. All explicit attributes shall be specified. The explicit attributes for this type are:

glossary-type

The attribute value shall be a Name. It shall be the glossary item type.

This type is refined by the following types:

5.2.2.16. Glossary Group Item Type#

This type refines the Glossary Item Type through the glossary-type attribute if the value is group. This set of attributes specifies a glossary group. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be a string. It shall be the human readable name of the glossary group.

text

The attribute value shall be a string. It shall state the requirement for the glossary group.

5.2.2.17. Glossary Term Item Type#

This type refines the Glossary Item Type through the glossary-type attribute if the value is term. This set of attributes specifies a glossary term. All explicit attributes shall be specified. The explicit attributes for this type are:

term

The attribute value shall be a string. It shall be the glossary term.

text

The attribute value shall be a string. It shall be the definition of the glossary term.

5.2.2.18. Interface Item Type#

This type refines the Root Item Type through the type attribute if the value is interface. This set of attributes specifies an interface specification item. Interface items shall specify the interface of the software product to other software products and the hardware. Use Interface Domain Item Type items to specify interface domains, for example the API, C language, compiler, interfaces to the implementation, and the hardware. All explicit attributes shall be specified. The explicit attributes for this type are:

index-entries

The attribute value shall be a list of strings. It shall be a list of additional document index entries. A document index entry derived from the interface name is added automatically.

interface-type

The attribute value shall be a Name. It shall be the interface item type.

This type is refined by the following types:

5.2.2.19. Application Configuration Group Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is appl-config-group. This set of attributes specifies an application configuration group. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be a string. It shall be the description of the application configuration group.

name

The attribute value shall be a string. It shall be human readable name of the application configuration group.

text

The attribute value shall be a Requirement Text. It shall state the requirement for the application configuration group.

5.2.2.20. Application Configuration Option Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is appl-config-option. This set of attributes specifies an application configuration option. All explicit attributes shall be specified. The explicit attributes for this type are:

appl-config-option-type

The attribute value shall be a Name. It shall be the application configuration option type.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be an Application Configuration Option Name.

notes

The attribute value shall be an Interface Notes.

This type is refined by the following types:

5.2.2.21. Application Configuration Feature Enable Option Item Type#

This type refines the Application Configuration Option Item Type through the appl-config-option-type attribute if the value is feature-enable. This set of attributes specifies an application configuration feature enable option.

5.2.2.22. Application Configuration Feature Option Item Type#

This type refines the Application Configuration Option Item Type through the appl-config-option-type attribute if the value is feature. This set of attributes specifies an application configuration feature option. All explicit attributes shall be specified. The explicit attributes for this type are:

default

The attribute value shall be a string. It shall describe what happens if the configuration option is undefined.

5.2.2.23. Application Configuration Value Option Item Type#

This type refines the following types:

This set of attributes specifies application configuration initializer or integer option. All explicit attributes shall be specified. The explicit attributes for this type are:

default-value

The attribute value shall be an Integer or String. It shall describe the default value of the application configuration option.

5.2.2.24. Interface Compound Item Type#

This type refines the following types:

This set of attributes specifies a compound (struct or union). All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be a list. Each list element shall be an Interface Compound Member Definition Directive.

definition-kind

The attribute value shall be an Interface Compound Definition Kind.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the compound (struct or union).

notes

The attribute value shall be an Interface Notes.

5.2.2.25. Interface Define Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is define. This set of attributes specifies a define. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be an Interface Definition Directive.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the define.

notes

The attribute value shall be an Interface Notes.

5.2.2.26. Interface Domain Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is domain. This set of attributes specifies an interface domain. Interface items are placed into domains through links with the Interface Placement Link Role. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be a string. It shall be the description of the domain

name

The attribute value shall be a string. It shall be the human readable name of the domain.

5.2.2.27. Interface Enum Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is enum. This set of attributes specifies an enum. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition-kind

The attribute value shall be an Interface Enum Definition Kind.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the enum.

notes

The attribute value shall be an Interface Description.

5.2.2.28. Interface Enumerator Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is enumerator. This set of attributes specifies an enumerator. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be an Interface Definition Directive.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the enumerator.

notes

The attribute value shall be an Interface Notes.

5.2.2.29. Interface Forward Declaration Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is forward-declaration. Items of this type specify a forward declaration. The item shall have exactly one link with the Interface Target Link Role to an Interface Compound Item Type item. This link defines the type declared by the forward declaration.

5.2.2.30. Interface Function or Macro Item Type#

This type refines the following types:

This set of attributes specifies a function or a macro. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be an Interface Function or Macro Definition Directive.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the function or macro.

notes

The attribute value shall be an Interface Notes.

params

The attribute value shall be a list. Each list element shall be an Interface Parameter.

return

The attribute value shall be an Interface Return Directive.

5.2.2.31. Interface Group Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is group. This set of attributes specifies an interface group. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

description

The attribute value shall be an Interface Description.

identifier

The attribute value shall be an Interface Group Identifier.

name

The attribute value shall be a string. It shall be the human readable name of the interface group.

text

The attribute value shall be a Requirement Text. It shall state the requirement for the interface group.

5.2.2.32. Interface Header File Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is header-file. This set of attributes specifies a header file. The item shall have exactly one link with the Interface Placement Link Role to an Interface Domain Item Type item. This link defines the interface domain of the header file. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

path

The attribute value shall be a string. It shall be the path used to include the header file. For example rtems/confdefs.h.

prefix

The attribute value shall be a string. It shall be the prefix directory path to the header file in the interface domain. For example cpukit/include.

5.2.2.33. Interface Typedef Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is typedef. This set of attributes specifies a typedef. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be an Interface Definition Directive.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the typedef.

notes

The attribute value shall be an Interface Notes.

params

The attribute value shall be a list. Each list element shall be an Interface Parameter.

return

The attribute value shall be an Interface Return Directive.

5.2.2.34. Interface Unspecified Header File Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is unspecified-header-file. This set of attributes specifies an unspecified header file. All explicit attributes shall be specified. The explicit attributes for this type are:

path

The attribute value shall be a string. It shall be the path used to include the header file. For example rtems/confdefs.h.

references

The attribute value shall be a list. Each list element shall be an External Reference.

5.2.2.35. Interface Unspecified Item Type#

This type refines the following types:

This set of attributes specifies an unspecified interface. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be a string. It shall be the name of the unspecified interface.

references

The attribute value shall be a list. Each list element shall be an External Reference.

5.2.2.36. Interface Variable Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is variable. This set of attributes specifies a variable. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be an Interface Definition Directive.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name of the variable.

notes

The attribute value shall be an Interface Notes.

5.2.2.37. Register Block Item Type#

This type refines the Interface Item Type through the interface-type attribute if the value is register-block. This set of attributes specifies a register block. A register block may be used to specify the interface of devices. Register blocks consist of register block members specified by the definition attribute. Register block members are either instances of registers specified by the registers attribute or instances of other register blocks specified by links with the Register Block Include Role. Registers consists of bit fields (see Register Bits Definition. The register block members are placed into the address space of the device relative to the base address of the register block. Register member offsets and the register block size are specified in units of the address space granule. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an Interface Brief Description.

definition

The attribute value shall be a list. Each list element shall be a Register Block Member Definition Directive.

description

The attribute value shall be an Interface Description.

identifier

The attribute value shall be an Interface Group Identifier.

name

The attribute value shall be a string. It shall be the name of the register block.

notes

The attribute value shall be an Interface Notes.

register-block-group

The attribute value shall be a string. It shall be the name of the interface group defined for the register block. For the group identifier see the identifier attribute.

register-block-size

The attribute value shall be an Optional Integer. If the value is present, then it shall be the size of the register block in units of the address space granule.

register-prefix

The attribute value shall be an optional string. If the value is present, then it will be used to prefix register bit field names, otherwise the value of the name attribute will be used.

registers

The attribute value shall be a list. Each list element shall be a Register Definition.

5.2.2.38. Proxy Item Types#

This type refines the Root Item Type through the type attribute if the value is proxy. Items of similar characteristics may link to a proxy item through links with the Proxy Member Link Role. A proxy item resolves to the first member item which is enabled. Proxies may be used to provide an interface with a common name and implementations which depend on configuration options. For example, in one configuration a constant could be a compile time constant and in another configuration it could be a read-only object.

5.2.2.39. Requirement Item Type#

This type refines the Root Item Type through the type attribute if the value is requirement. This set of attributes specifies a requirement. All explicit attributes shall be specified. The explicit attributes for this type are:

rationale

The attribute value shall be an optional string. If the value is present, then it shall state the rationale or justification of the requirement.

references

The attribute value shall be a list. Each list element shall be an External Reference.

requirement-type

The attribute value shall be a Name. It shall be the requirement item type.

text

The attribute value shall be a Requirement Text. It shall state the requirement.

This type is refined by the following types:

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
enabled-by: true
functional-type: capability
links: []
rationale: |
  It keeps you busy.
requirement-type: functional
text: |
  The system shall do crazy things.
type: requirement
5.2.2.40. Functional Requirement Item Type#

This type refines the Requirement Item Type through the requirement-type attribute if the value is functional. This set of attributes specifies a functional requirement. All explicit attributes shall be specified. The explicit attributes for this type are:

functional-type

The attribute value shall be a Name. It shall be the functional type of the requirement.

This type is refined by the following types:

5.2.2.41. Action Requirement Item Type#

This type refines the Functional Requirement Item Type through the functional-type attribute if the value is action. This set of attributes specifies functional requirements and corresponding validation test code. The functional requirements of an action are specified. An action performs a step in a finite state machine. An action is implemented through a function or a macro. The action is performed through a call of the function or an execution of the code of a macro expansion by an actor. The actor is for example a task or an interrupt service routine.

For action requirements which specify the function of an interface, there shall be exactly one link with the Interface Function Link Role to the interface of the action.

The action requirements are specified by

  • a list of pre-conditions, each with a set of states,

  • a list of post-conditions, each with a set of states,

  • the transition of pre-condition states to post-condition states through the action.

Along with the requirements, the test code to generate a validation test is specified. For an action requirement it is verified that all variations of pre-condition states have a set of post-condition states specified in the transition map. All transitions are covered by the generated test code. All explicit attributes shall be specified. The explicit attributes for this type are:

post-conditions

The attribute value shall be a list. Each list element shall be an Action Requirement Condition.

pre-conditions

The attribute value shall be a list. Each list element shall be an Action Requirement Condition.

skip-reasons

The attribute value shall be an Action Requirement Skip Reasons.

test-action

The attribute value shall be a string. It shall be the test action code.

test-brief

The attribute value shall be an optional string. If the value is present, then it shall be the test case brief description.

test-cleanup

The attribute value shall be an optional string. If the value is present, then it shall be the test cleanup code. The code is placed in the test action loop body after the test post-condition checks.

test-context

The attribute value shall be a list. Each list element shall be a Test Context Member.

test-context-support

The attribute value shall be an optional string. If the value is present, then it shall be the test context support code. The context support code is placed at file scope before the test context definition.

test-description

The attribute value shall be an optional string. If the value is present, then it shall be the test case description.

test-header

The attribute value shall be a Test Header.

test-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include <...>.

test-local-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include "...".

test-prepare

The attribute value shall be an optional string. If the value is present, then it shall be the early test preparation code. The code is placed in the test action loop body before the test pre-condition preparations.

test-setup

The attribute value shall be a Test Support Method.

test-stop

The attribute value shall be a Test Support Method.

test-support

The attribute value shall be an optional string. If the value is present, then it shall be the test case support code. The support code is placed at file scope before the test case code.

test-target

The attribute value shall be a string. It shall be the path to the generated test case source file.

test-teardown

The attribute value shall be a Test Support Method.

transition-map

The attribute value shall be a list. Each list element shall be an Action Requirement Transition.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
enabled-by: true
functional-type: action
links: []
post-conditions:
- name: Status
  states:
  - name: Success
    test-code: |
      /* Check that the status is SUCCESS */
    text: |
      The status shall be SUCCESS.
  - name: Error
    test-code: |
      /* Check that the status is ERROR */
    text: |
      The status shall be ERROR.
  test-epilogue: null
  test-prologue: null
- name: Data
  states:
  - name: Unchanged
    test-code: |
      /* Check that the data is unchanged */
    text: |
      The data shall be unchanged by the action.
  - name: Red
    test-code: |
      /* Check that the data is red */
    text: |
      The data shall be red.
  - name: Green
    test-code: |
      /* Check that the data is green */
    text: |
      The data shall be green.
  test-epilogue: null
  test-prologue: null
pre-conditions:
- name: Data
  states:
  - name: NullPtr
    test-code: |
      /* Set data pointer to NULL */
    text: |
      The data pointer shall be NULL.
  - name: Valid
    test-code: |
      /* Set data pointer to reference a valid data buffer */
    text: |
      The data pointer shall reference a valid data buffer.
  test-epilogue: null
  test-prologue: null
- name: Option
  states:
  - name: Red
    test-code: |
      /* Set option to RED */
    text: |
      The option shall be RED.
  - name: Green
    test-code: |
      /* Set option to GREEN */
    text: |
      The option shall be GREEN.
  test-epilogue: null
  test-prologue: null
requirement-type: functional
skip-reasons: {}
test-action: |
  /* Call the function of the action */
test-brief: null
test-cleanup: null
test-context:
- brief: null
  description: null
  member: void *data
- brief: null
  description: null
  member: option_type option
test-context-support: null
test-description: null
test-header: null
test-includes: []
test-local-includes: []
test-prepare: null
test-setup: null
test-stop: null
test-support: null
test-target: tc-red-green-data.c
test-teardown: null
transition-map:
- enabled-by: true
  post-conditions:
    Status: Error
    Data: Unchanged
  pre-conditions:
    Data: NullPtr
    Option: all
- enabled-by: true
  post-conditions:
    Status: Success
    Data: Red
  pre-conditions:
    Data: Valid
    Option: Red
- enabled-by: true
  post-conditions:
    Status: Success
    Data: Green
  pre-conditions:
    Data: Valid
    Option: Green
rationale: null
references: []
text: |
  ${.:/text-template}
type: requirement
5.2.2.42. Generic Functional Requirement Item Type#

This type refines the following types:

Items of this type state a functional requirement with the functional type defined by the specification type refinement.

5.2.2.43. Non-Functional Requirement Item Type#

This type refines the Requirement Item Type through the requirement-type attribute if the value is non-functional. This set of attributes specifies a non-functional requirement. All explicit attributes shall be specified. The explicit attributes for this type are:

non-functional-type

The attribute value shall be a Name. It shall be the non-functional type of the requirement.

This type is refined by the following types:

5.2.2.44. Design Group Requirement Item Type#

This type refines the Non-Functional Requirement Item Type through the non-functional-type attribute if the value is design-group. This set of attributes specifies a design group requirement. Design group requirements have an explicit reference to the associated Doxygen group specified by the identifier attribute. Design group requirements have an implicit validation by inspection method. The qualification toolchain shall perform the inspection and check that the specified Doxygen group exists in the software source code. All explicit attributes shall be specified. The explicit attributes for this type are:

identifier

The attribute value shall be a Requirement Design Group Identifier.

5.2.2.45. Design Target Item Type#

This type refines the Non-Functional Requirement Item Type through the non-functional-type attribute if the value is design-target. This set of attributes specifies a design target. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an optional string. If the value is present, then it shall briefly describe the target.

description

The attribute value shall be an optional string. If the value is present, then it shall thoroughly describe the target.

name

The attribute value shall be a string. It shall be the target name.

5.2.2.46. Generic Non-Functional Requirement Item Type#

This type refines the following types:

Items of this type state a non-functional requirement with the non-functional type defined by the specification type refinement.

5.2.2.47. Runtime Measurement Environment Item Type#

This type refines the Non-Functional Requirement Item Type through the non-functional-type attribute if the value is performance-runtime-environment. This set of attributes specifies a runtime measurement environment. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be a string. It shall be the runtime measurement environment name. See also Runtime Measurement Environment Name.

5.2.2.48. Runtime Performance Requirement Item Type#

This type refines the Non-Functional Requirement Item Type through the non-functional-type attribute if the value is performance-runtime. The item shall have exactly one link with the Runtime Measurement Request Link Role. A requirement text processor shall support a substitution of ${.:/limit-kind}:

A requirement text processor shall support a substitution of ${.:/limit-condition}:

A requirement text processor shall support a substitution of ${.:/environment}. The value of the substitution shall be "<environment> environment" with <environment> being the environment of the corresponding entry in the Runtime Measurement Environment Table.

This set of attributes specifies a runtime performance requirement. Along with the requirement, the validation test code to execute a measure runtime request is specified. All explicit attributes shall be specified. The explicit attributes for this type are:

params

The attribute value shall be a Runtime Performance Parameter Set.

test-body

The attribute value shall be a Test Support Method. It shall provide the code of the measure runtime body handler. In contrast to other methods, this method is mandatory.

test-cleanup

The attribute value shall be a Test Support Method. It may provide the code to clean up the measure runtime request. This method is called before the cleanup method of the corresponding Runtime Measurement Test Item Type item and after the request.

test-prepare

The attribute value shall be a Test Support Method. It may provide the code to prepare the measure runtime request. This method is called after the prepare method of the corresponding Runtime Measurement Test Item Type item and before the request.

test-setup

The attribute value shall be a Test Support Method. It may provide the code of the measure runtime setup handler.

test-teardown

The attribute value shall be a Test Support Method. It may provide the code of the measure runtime teardown handler.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
enabled-by: true
links:
- role: runtime-measurement-request
  uid: ../val/perf
params: {}
rationale: null
references: []
test-body:
  brief: |
    Get a buffer.
  code: |
    ctx->status = rtems_partition_get_buffer( ctx->part_many, &ctx->buffer );
  description: null
test-cleanup: null
test-prepare: null
test-setup: null
test-teardown:
  brief: |
    Return the buffer.
  code: |
    rtems_status_code sc;

    T_quiet_rsc_success( ctx->status );

    sc = rtems_partition_return_buffer( ctx->part_many, ctx->buffer );
    T_quiet_rsc_success( sc );

    return tic == toc;
  description: null
text: |
  When a partition has exactly ${../val/perf:/params/buffer-count} free
  buffers, the ${.:/limit-kind} runtime of exactly
  ${../val/perf:/params/sample-count} successful calls to
  ${../if/get-buffer:/name} in the ${.:/environment} shall be
  ${.:/limit-condition}.
non-functional-type: performance-runtime
requirement-type: non-functional
type: requirement
5.2.2.49. Requirement Validation Item Type#

This type refines the Root Item Type through the type attribute if the value is validation. This set of attributes provides a requirement validation evidence. The item shall have exactly one link to the validated requirement with the Requirement Validation Link Role. All explicit attributes shall be specified. The explicit attributes for this type are:

method

The attribute value shall be a Name. It shall specify the requirement validation method (except validation by test). Validation by test is done through Test Case Item Type items.

references

The attribute value shall be a list. Each list element shall be an External Reference.

text

The attribute value shall be a string. It shall provide the validation evidence depending on the validation method:

  • By analysis: A statement shall be provided how the requirement is met, by analysing static properties of the software product.

  • By inspection: A statement shall be provided how the requirement is met, by inspection of the source code.

  • By review of design: A rationale shall be provided to demonstrate how the requirement is satisfied implicitly by the software design.

This type is refined by the following types:

5.2.2.50. Requirement Validation Method#

This type refines the following types:

5.2.2.51. Runtime Measurement Test Item Type#

This type refines the Root Item Type through the type attribute if the value is runtime-measurement-test. This set of attributes specifies a runtime measurement test case. All explicit attributes shall be specified. The explicit attributes for this type are:

params

The attribute value shall be a Runtime Measurement Parameter Set.

test-brief

The attribute value shall be an optional string. If the value is present, then it shall be the test case brief description.

test-cleanup

The attribute value shall be a Test Support Method. If the value is present, then it shall be the measure runtime request cleanup method. The method is called after each measure runtime request.

test-context

The attribute value shall be a list. Each list element shall be a Test Context Member.

test-context-support

The attribute value shall be an optional string. If the value is present, then it shall be the test context support code. The context support code is placed at file scope before the test context definition.

test-description

The attribute value shall be an optional string. If the value is present, then it shall be the test case description.

test-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include <...>.

test-local-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include "...".

test-prepare

The attribute value shall be a Test Support Method. If the value is present, then it shall be the measure runtime request prepare method. The method is called before each measure runtime request.

test-setup

The attribute value shall be a Test Support Method. If the value is present, then it shall be the test case setup fixture method.

test-stop

The attribute value shall be a Test Support Method. If the value is present, then it shall be the test case stop fixture method.

test-support

The attribute value shall be an optional string. If the value is present, then it shall be the test case support code. The support code is placed at file scope before the test case code.

test-target

The attribute value shall be a string. It shall be the path to the generated test case source file.

test-teardown

The attribute value shall be a Test Support Method. If the value is present, then it shall be the test case teardown fixture method.

5.2.2.52. Specification Item Type#

This type refines the Root Item Type through the type attribute if the value is spec. This set of attributes specifies specification types. All explicit attributes shall be specified. The explicit attributes for this type are:

spec-description

The attribute value shall be an optional string. It shall be the description of the specification type.

spec-example

The attribute value shall be an optional string. If the value is present, then it shall be an example of the specification type.

spec-info

The attribute value shall be a Specification Information.

spec-name

The attribute value shall be an optional string. It shall be the human readable name of the specification type.

spec-type

The attribute value shall be a Name. It shall the specification type.

Please have a look at the following example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
copyrights:
- Copyright (C) 2020 embedded brains GmbH & Co. KG
enabled-by: true
links:
- role: spec-member
  uid: root
- role: spec-refinement
  spec-key: type
  spec-value: example
  uid: root
spec-description: null
spec-example: null
spec-info:
  dict:
    attributes:
      an-example-attribute:
        description: |
          It shall be an example.
        spec-type: optional-str
      example-number:
        description: |
          It shall be the example number.
        spec-type: int
    description: |
      This set of attributes specifies an example.
    mandatory-attributes: all
spec-name: Example Item Type
spec-type: spec
type: spec
5.2.2.53. Test Case Item Type#

This type refines the Root Item Type through the type attribute if the value is test-case. This set of attributes specifies a test case. All explicit attributes shall be specified. The explicit attributes for this type are:

test-actions

The attribute value shall be a list. Each list element shall be a Test Case Action.

test-brief

The attribute value shall be a string. It shall be the test case brief description.

test-context

The attribute value shall be a list. Each list element shall be a Test Context Member.

test-context-support

The attribute value shall be an optional string. If the value is present, then it shall be the test context support code. The context support code is placed at file scope before the test context definition.

test-description

The attribute value shall be an optional string. It shall be the test case description.

test-header

The attribute value shall be a Test Header.

test-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include <...>.

test-local-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include "...".

test-setup

The attribute value shall be a Test Support Method.

test-stop

The attribute value shall be a Test Support Method.

test-support

The attribute value shall be an optional string. If the value is present, then it shall be the test case support code. The support code is placed at file scope before the test case code.

test-target

The attribute value shall be a string. It shall be the path to the generated target test case source file.

test-teardown

The attribute value shall be a Test Support Method.

5.2.2.54. Test Platform Item Type#

This type refines the Root Item Type through the type attribute if the value is test-platform. Please note:

Warning

This item type is work in progress.

This set of attributes specifies a test platform. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be a string. It shall be the description of the test platform.

name

The attribute value shall be a string. It shall be the human readable name of the test platform.

5.2.2.55. Test Procedure Item Type#

This type refines the Root Item Type through the type attribute if the value is test-procedure. Please note:

Warning

This item type is work in progress.

This set of attributes specifies a test procedure. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be a string. It shall be the human readable name of the test procedure.

purpose

The attribute value shall be a string. It shall state the purpose of the test procedure.

steps

The attribute value shall be a string. It shall describe the steps of the test procedure execution.

5.2.2.56. Test Suite Item Type#

This type refines the following types:

  • Root Item Type through the type attribute if the value is memory-benchmark

  • Root Item Type through the type attribute if the value is test-suite

This set of attributes specifies a test suite. All explicit attributes shall be specified. The explicit attributes for this type are:

test-brief

The attribute value shall be a string. It shall be the test suite brief description.

test-code

The attribute value shall be a string. It shall be the test suite code. The test suite code is placed at file scope in the target source file.

test-description

The attribute value shall be an optional string. It shall be the test suite description.

test-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include <...>.

test-local-includes

The attribute value shall be a list of strings. It shall be a list of header files included via #include "...".

test-target

The attribute value shall be a string. It shall be the path to the generated target test suite source file.

5.2.3. Specification Attribute Sets and Value Types#

5.2.3.1. Action Requirement Boolean Expression#

A value of this type is a boolean expression.

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. Each attribute defines an operator. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

    and

    The attribute value shall be a list. Each list element shall be an Action Requirement Boolean Expression. The and operator evaluates to the logical and of the evaluation results of the expressions in the list.

    not

    The attribute value shall be an Action Requirement Boolean Expression. The not operator evaluates to the logical not of the evaluation results of the expression.

    or

    The attribute value shall be a list. Each list element shall be an Action Requirement Boolean Expression. The or operator evaluates to the logical or of the evaluation results of the expressions in the list.

    post-conditions

    The attribute value shall be an Action Requirement Expression Condition Set. The post-conditions operator evaluates to true, if the post-condition states of the associated transition are contained in the specified post-condition set, otherwise to false.

    pre-conditions

    The attribute value shall be an Action Requirement Expression Condition Set. The pre-conditions operator evaluates to true, if the pre-condition states of the associated transition are contained in the specified pre-condition set, otherwise to false.

  • The value may be a list. Each list element shall be an Action Requirement Boolean Expression. This list of expressions evaluates to the logical or of the evaluation results of the expressions in the list.

This type is used by the following types:

5.2.3.2. Action Requirement Condition#

This set of attributes defines an action pre-condition or post-condition. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be an Action Requirement Name.

states

The attribute value shall be a list. Each list element shall be an Action Requirement State.

test-epilogue

The attribute value shall be an optional string. If the value is present, then it shall be the test epilogue code. The epilogue code is placed in the test condition preparation or check before the state-specific code. The code may use a local variable ctx which points to the test context, see Test Context Member.

test-prologue

The attribute value shall be an optional string. If the value is present, then it shall be the test prologue code. The prologue code is placed in the test condition preparation or check after the state-specific code. The code may use a local variable ctx which points to the test context, see Test Context Member.

This type is used by the following types:

5.2.3.3. Action Requirement Expression#

This set of attributes defines an expression which may define the state of a post-condition. The else and specified-by shall be used individually. The if and then or then-specified-by expressions shall be used together. At least one of the explicit attributes shall be specified. The explicit attributes for this type are:

else

The attribute value shall be an Action Requirement Expression State Name. It shall be the name of the state of the post-condition.

if

The attribute value shall be an Action Requirement Boolean Expression. If the boolean expression evaluates to true, then the state is defined according to the then attribute value.

specified-by

The attribute value shall be an Action Requirement Name. It shall be the name of a pre-condition. The name of the state of the pre-condition in the associated transition defines the name of the state of the post-condition.

then

The attribute value shall be an Action Requirement Expression State Name. It shall be the name of the state of the post-condition.

then-specified-by

The attribute value shall be an Action Requirement Name. It shall be the name of a pre-condition. The name of the state of the pre-condition in the associated transition defines the name of the state of the post-condition.

5.2.3.4. Action Requirement Expression Condition Set#

This set of attributes defines for the specified conditions a set of states. Generic attributes may be specified. Each generic attribute key shall be an Action Requirement Name. Each generic attribute value shall be an Action Requirement Expression State Set. There shall be at most one generic attribute key for each condition. The key name shall be the condition name. The value of each generic attribute shall be a set of states of the condition.

This type is used by the following types:

5.2.3.5. Action Requirement Expression State Name#

The value shall be a string. It shall be the name of a state of the condition or N/A if the condition is not applicable. The value

  • shall match with the regular expression “^[A-Z][a-zA-Z0-9]*$”,

  • or, shall be equal to “N/A”.

This type is used by the following types:

5.2.3.6. Action Requirement Expression State Set#

A value of this type shall be of one of the following variants:

  • The value may be a list. Each list element shall be an Action Requirement Expression State Name. The list defines a set of states of the condition.

  • The value may be a string. It shall be the name of a state of the condition or N/A if the condition is not applicable. The value

    • shall match with the regular expression “^[A-Z][a-zA-Z0-9]*$”,

    • or, shall be equal to “N/A”.

This type is used by the following types:

5.2.3.7. Action Requirement Name#

The value shall be a string. It shall be the name of a condition or a state of a condition used to define pre-conditions and post-conditions of an action requirement. It shall be formatted in CamelCase. It should be brief and abbreviated. The rationale for this is that the names are used in tables and the horizontal space is limited by the page width. The more conditions you have in an action requirement, the shorter the names should be. The name NA is reserved and indicates that a condition is not applicable. The value

  • shall match with the regular expression “^[A-Z][a-zA-Z0-9]*$”,

  • and, shall be not equal to “NA”.

This type is used by the following types:

5.2.3.8. Action Requirement Skip Reasons#

This set of attributes specifies skip reasons used to justify why transitions in the transition map are skipped. Generic attributes may be specified. Each generic attribute key shall be an Action Requirement Name. Each generic attribute value shall be a string. The key defines the name of a skip reason. The name can be used in Action Requirement Transition Post-Conditions to skip the corresponding transitions. The value shall give a reason why the transitions are skipped.

This type is used by the following types:

5.2.3.9. Action Requirement State#

This set of attributes defines an action pre-condition or post-condition state. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be an Action Requirement Name.

test-code

The attribute value shall be a string. It shall be the test code to prepare or check the state of the condition. The code may use a local variable ctx which points to the test context, see Test Context Member.

text

The attribute value shall be a Requirement Text. It shall define the state of the condition.

This type is used by the following types:

5.2.3.10. Action Requirement Transition#

This set of attributes defines the transition from multiple sets of states of pre-conditions to a set of states of post-conditions through an action in an action requirement. The ability to specify multiple sets of states of pre-conditions which result in a common set of post-conditions may allow a more compact specification of the transition map. For example, let us suppose you want to specify the action of a function with a pointer parameter. The function performs an early check that the pointer is NULL and in this case returns an error code. The pointer condition dominates the action outcome if the pointer is NULL. Other pre-condition states can be simply set to all for this transition. All explicit attributes shall be specified. The explicit attributes for this type are:

enabled-by

The attribute value shall be an Enabled-By Expression. The transition map may be customized to support configuration variants through this attribute. The default transitions (enabled-by: true) shall be specified before the customized variants in the list.

post-conditions

The attribute value shall be an Action Requirement Transition Post-Conditions.

pre-conditions

The attribute value shall be an Action Requirement Transition Pre-Conditions.

This type is used by the following types:

5.2.3.11. Action Requirement Transition Post-Condition State#

A value of this type shall be of one of the following variants:

  • The value may be a list. Each list element shall be an Action Requirement Expression. The list contains expressions to define the state of the corresponding post-condition.

  • The value may be a string. It shall be the name of a state of the corresponding post-condition or N/A if the post-condition is not applicable. The value

    • shall match with the regular expression “^[A-Z][a-zA-Z0-9]*$”,

    • or, shall be equal to “N/A”.

This type is used by the following types:

5.2.3.12. Action Requirement Transition Post-Conditions#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes defines for each post-condition the state after the action for a transition in an action requirement. Generic attributes may be specified. Each generic attribute key shall be an Action Requirement Name. Each generic attribute value shall be an Action Requirement Transition Post-Condition State. There shall be exactly one generic attribute key for each post-condition. The key name shall be the post-condition name. The value of each generic attribute shall be the state of the post-condition or N/A if the post-condition is not applicable.

  • The value may be a string. It shall be the name of a skip reason. If a skip reason is given instead of a listing of post-condition states, then this transition is skipped and no test code runs for this transition. The value

    • shall match with the regular expression “^[A-Z][a-zA-Z0-9]*$”,

    • and, shall be not equal to “NA”.

This type is used by the following types:

5.2.3.13. Action Requirement Transition Pre-Condition State Set#

A value of this type shall be of one of the following variants:

  • The value may be a list. Each list element shall be an Action Requirement Name. The list defines the set of states of the pre-condition in the transition.

  • The value may be a string. The value all represents all states of the pre-condition in this transition. The value N/A marks the pre-condition as not applicable in this transition. The value shall be an element of

    • all”, and

    • N/A”.

This type is used by the following types:

5.2.3.14. Action Requirement Transition Pre-Conditions#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes defines for each pre-condition the set of states before the action for a transition in an action requirement. Generic attributes may be specified. Each generic attribute key shall be an Action Requirement Name. Each generic attribute value shall be an Action Requirement Transition Pre-Condition State Set. There shall be exactly one generic attribute key for each pre-condition. The key name shall be the pre-condition name. The value of each generic attribute shall be a set of states of the pre-condition.

  • The value may be a string. If this name is specified instead of explicit pre-condition states, then the post-condition states of this entry are used to define all remaining transitions of the map. The value shall be equal to “default”.

This type is used by the following types:

5.2.3.15. Application Configuration Option Name#

The value shall be a string. It shall be the name of an application configuration option. The value shall match with the regular expression “^(CONFIGURE_|BSP_)[A-Z0-9_]+$”.

This type is used by the following types:

5.2.3.16. Boolean or Integer or String#

A value of this type shall be of one of the following variants:

  • The value may be a boolean.

  • The value may be an integer number.

  • The value may be a string.

This type is used by the following types:

5.2.3.17. Build Assembler Option#

The value shall be a string. It shall be an option for the assembler. The options are used to assemble the sources of this item. The options defined by this attribute succeed the options presented to the item by the build item context.

This type is used by the following types:

5.2.3.18. Build C Compiler Option#

The value shall be a string. It shall be an option for the C compiler. The options are used to compile the sources of this item. The options defined by this attribute succeed the options presented to the item by the build item context.

This type is used by the following types:

5.2.3.19. Build C Preprocessor Option#

The value shall be a string. It shall be an option for the C preprocessor. The options are used to preprocess the sources of this item. The options defined by this attribute succeed the options presented to the item by the build item context.

This type is used by the following types:

5.2.3.20. Build C++ Compiler Option#

The value shall be a string. It shall be an option for the C++ compiler. The options are used to compile the sources of this item. The options defined by this attribute succeed the options presented to the item by the build item context.

This type is used by the following types:

5.2.3.23. Build Include Path#

The value shall be a string. It shall be a path to header files. The path is used by the C preprocessor to search for header files. It succeeds the includes presented to the item by the build item context. For an Build Group Item Type item the includes are visible to all items referenced by the group item. For Build BSP Item Type, Build Objects Item Type, Build Library Item Type, Build Start File Item Type, and Build Test Program Item Type items the includes are only visible to the sources specified by the item itself and they do not propagate to referenced items.

This type is used by the following types:

5.2.3.24. Build Install Directive#

This set of attributes specifies files installed by a build item. All explicit attributes shall be specified. The explicit attributes for this type are:

destination

The attribute value shall be a string. It shall be the install destination directory.

source

The attribute value shall be a list of strings. It shall be the list of source files to be installed in the destination directory. The path to a source file shall be relative to the directory of the wscript.

This type is used by the following types:

5.2.3.25. Build Install Path#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It shall be the installation path of a Build Target.

This type is used by the following types:

5.2.3.27. Build Linker Option#

The value shall be a string. It shall be an option for the linker. The options are used to link executables. The options defined by this attribute succeed the options presented to the item by the build item context.

This type is used by the following types:

5.2.3.28. Build Option Action#

This set of attributes specifies a build option action. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

append-test-cppflags

The attribute value shall be a string. It shall be the name of a test program. The action appends the action value to the CPPFLAGS of the test program. The name shall correspond to the name of a Build Test Program Item Type item. Due to the processing order of items, there is no way to check if the name specified by the attribute value is valid.

assert-aligned

The attribute value shall be an integer number. The action asserts that the action value is aligned according to the attribute value.

assert-eq

The attribute value shall be a Boolean or Integer or String. The action asserts that the action value is equal to the attribute value.

assert-ge

The attribute value shall be an Integer or String. The action asserts that the action value is greater than or equal to the attribute value.

assert-gt

The attribute value shall be an Integer or String. The action asserts that the action value is greater than the attribute value.

assert-in-set

The attribute value shall be a list. Each list element shall be an Integer or String. The action asserts that the action value is in the attribute value set.

assert-int16

The attribute shall have no value. The action asserts that the action value is a valid signed 16-bit integer.

assert-int32

The attribute shall have no value. The action asserts that the action value is a valid signed 32-bit integer.

assert-int64

The attribute shall have no value. The action asserts that the action value is a valid signed 64-bit integer.

assert-int8

The attribute shall have no value. The action asserts that the action value is a valid signed 8-bit integer.

assert-le

The attribute value shall be an Integer or String. The action asserts that the action value is less than or equal to the attribute value.

assert-lt

The attribute value shall be an Integer or String. The action asserts that the action value is less than the attribute value.

assert-ne

The attribute value shall be a Boolean or Integer or String. The action asserts that the action value is not equal to the attribute value.

assert-power-of-two

The attribute shall have no value. The action asserts that the action value is a power of two.

assert-uint16

The attribute shall have no value. The action asserts that the action value is a valid unsigned 16-bit integer.

assert-uint32

The attribute shall have no value. The action asserts that the action value is a valid unsigned 32-bit integer.

assert-uint64

The attribute shall have no value. The action asserts that the action value is a valid unsigned 64-bit integer.

assert-uint8

The attribute shall have no value. The action asserts that the action value is a valid unsigned 8-bit integer.

check-cc

The attribute value shall be a Build Option C Compiler Check Action.

check-cxx

The attribute value shall be a Build Option C++ Compiler Check Action.

comment

The attribute value shall be a string. There is no action performed. The attribute value is a comment.

define

The attribute value shall be an optional string. The action adds a define to the configuration set. If the attribute value is present, then it is used as the name of the define, otherwise the name of the item is used. The value of the define is the action value. If the action value is a string, then it is quoted.

define-condition

The attribute value shall be an optional string. The action adds a conditional define to the configuration set. If the attribute value is present, then it is used as the name of the define, otherwise the name of the item is used. The value of the define is the action value.

define-unquoted

The attribute value shall be an optional string. The action adds a define to the configuration set. If the attribute value is present, then it is used as the name of the define, otherwise the name of the item is used. The value of the define is the action value. If the action value is a string, then it is not quoted.

env-append

The attribute value shall be an optional string. The action appends the action value to an environment of the configuration set. If the attribute value is present, then it is used as the name of the environment variable, otherwise the name of the item is used.

env-assign

The attribute value shall be an optional string. The action assigns the action value to an environment of the configuration set. If the attribute value is present, then it is used as the name of the environment variable, otherwise the name of the item is used.

env-enable

The attribute value shall be an optional string. If the action value is true, then a name is appended to the ENABLE environment variable of the configuration set. If the attribute value is present, then it is used as the name, otherwise the name of the item is used.

find-program

The attribute shall have no value. The action tries to find the program specified by the action value. Uses the ${PATH} to find the program. Returns the result of the find operation, e.g. a path to the program.

find-tool

The attribute shall have no value. The action tries to find the tool specified by the action value. Uses the tool paths specified by the --rtems-tools command line option. Returns the result of the find operation, e.g. a path to the program.

format-and-define

The attribute value shall be an optional string. The action adds a define to the configuration set. If the attribute value is present, then it is used as the name of the define, otherwise the name of the item is used. The value of the define is the action value. The value is formatted according to the format attribute value.

get-boolean

The attribute shall have no value. The action gets the action value for subsequent actions from a configuration file variable named by the items name attribute. If no such variable exists in the configuration file, then the default value is used. The value is converted to a boolean.

get-env

The attribute value shall be a string. The action gets the action value for subsequent actions from the environment variable of the configuration set named by the attribute value.

get-integer

The attribute shall have no value. The action gets the action value for subsequent actions from a configuration file variable named by the items name attribute. If no such variable exists in the configuration file, then the default value is used. The value is converted to an integer.

get-string

The attribute shall have no value. The action gets the action value for subsequent actions from a configuration file variable named by the items name attribute. If no such variable exists in the configuration file, then the default value is used. The value is converted to a string.

get-string-command-line

The attribute value shall be a string. The action gets the action value for subsequent actions from the value of a command line option named by the items name attribute. If no such command line option is present, then the attribute value is used. The value is converted to a string.

script

The attribute value shall be a string. The action executes the attribute value with the Python eval() function in the context of the script action handler.

set-test-state

The attribute value shall be a Build Option Set Test State Action.

set-value

The attribute value may have any type. The action sets the action value for subsequent actions to the attribute value.

set-value-enabled-by

The attribute value shall be a list. Each list element shall be a Build Option Value. The action sets the action value for subsequent actions to the first enabled attribute value.

split

The attribute shall have no value. The action splits the action value.

substitute

The attribute shall have no value. The action performs a ${VARIABLE} substitution on the action value. Use $$ for a plain $ character.

This type is used by the following types:

5.2.3.29. Build Option C Compiler Check Action#

This set of attributes specifies a check done using the C compiler. All explicit attributes shall be specified. The explicit attributes for this type are:

cflags

The attribute value shall be a list. Each list element shall be a Build C Compiler Option.

fragment

The attribute value shall be a string. It shall be a code fragment used to check the availability of a certain feature through compilation with the C compiler. The resulting object is not linked to an executable.

message

The attribute value shall be a string. It shall be a description of the feature to check.

This type is used by the following types:

5.2.3.30. Build Option C++ Compiler Check Action#

This set of attributes specifies a check done using the C++ compiler. All explicit attributes shall be specified. The explicit attributes for this type are:

cxxflags

The attribute value shall be a list. Each list element shall be a Build C++ Compiler Option.

fragment

The attribute value shall be a string. It shall be a code fragment used to check the availability of a certain feature through compilation with the C++ compiler. The resulting object is not linked to an executable.

message

The attribute value shall be a string. It shall be a description of the feature to check.

This type is used by the following types:

5.2.3.31. Build Option Name#

The value shall be a string. It shall be the name of the build option. The value shall match with the regular expression “^[a-zA-Z_][a-zA-Z0-9_]*$”.

This type is used by the following types:

5.2.3.32. Build Option Set Test State Action#

This set of attributes specifies the test state for a set of test programs with an optional reason. All explicit attributes shall be specified. The explicit attributes for this type are:

reason

The attribute value shall be an optional string. If the value is present, then it shall be the reason for the test state definition.

state

The attribute value shall be a Build Test State. It shall be the test state for the associated list of tests.

tests

The attribute value shall be a list of strings. It shall be the list of test program names associated with the test state. The names shall correspond to the name of a Build Test Program Item Type or Build Ada Test Program Item Type item. Due to the processing order of items, there is no way to check if a specified test program name is valid.

This type is used by the following types:

5.2.3.33. Build Option Value#

This set of attributes specifies an optional build option value. All explicit attributes shall be specified. The explicit attributes for this type are:

enabled-by

The attribute value shall be an Enabled-By Expression.

value

The attribute value may have any type. If the associated enabled-by expression evaluates to true for the current enabled set, then the attribute value is active and may get selected.

This type is used by the following types:

5.2.3.34. Build Source#

The value shall be a string. It shall be a source file. The path to a source file shall be relative to the directory of the wscript.

This type is used by the following types:

5.2.3.35. Build Target#

The value shall be a string. It shall be the target file path. The path to the target file shall be relative to the directory of the wscript. The target file is located in the build tree.

This type is used by the following types:

5.2.3.36. Build Test State#

The value shall be a string. This string defines a test state. The value shall be an element of

  • benchmark”,

  • exclude”,

  • expected-fail”,

  • indeterminate”, and

  • user-input”.

This type is used by the following types:

5.2.3.37. Build Use After Directive#

The value shall be a string. It shall be an internal static library identifier. The library is used to link programs referenced by this item, e.g. z for libz.a. The library is placed after the use items of the build item context.

This type is used by the following types:

5.2.3.38. Build Use Before Directive#

The value shall be a string. It shall be an internal static library identifier. The library is used to link programs referenced by this item, e.g. z for libz.a. The library is placed before the use items of the build item context.

This type is used by the following types:

5.2.3.41. Enabled-By Expression#

A value of this type shall be an expression which defines under which conditions the specification item or parts of it are enabled. The expression is evaluated with the use of an enabled set. This is a set of strings which indicate enabled features.

A value of this type shall be of one of the following variants:

  • The value may be a boolean. This expression evaluates directly to the boolean value.

  • The value may be a set of attributes. Each attribute defines an operator. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

    and

    The attribute value shall be a list. Each list element shall be an Enabled-By Expression. The and operator evaluates to the logical and of the evaluation results of the expressions in the list.

    not

    The attribute value shall be an Enabled-By Expression. The not operator evaluates to the logical not of the evaluation results of the expression.

    or

    The attribute value shall be a list. Each list element shall be an Enabled-By Expression. The or operator evaluates to the logical or of the evaluation results of the expressions in the list.

  • The value may be a list. Each list element shall be an Enabled-By Expression. This list of expressions evaluates to the logical or of the evaluation results of the expressions in the list.

  • The value may be a string. If the value is in the enabled set, this expression evaluates to true, otherwise to false.

This type is used by the following types:

Please have a look at the following example:

enabled-by:
  and:
  - RTEMS_NETWORKING
  - not: RTEMS_SMP
5.2.3.42. External Document Reference#

This type refines the External Reference through the type attribute if the value is document. It specifies a reference to a document.

All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be a string. It shall be the name of the document.

5.2.3.43. External File Reference#

This type refines the External Reference through the type attribute if the value is file. It specifies a reference to a file.

All explicit attributes shall be specified. The explicit attributes for this type are:

hash

The attribute value shall be a SHA256 Hash Value. It shall be the SHA256 hash value of the content of the referenced file.

5.2.3.44. External Reference#

This set of attributes specifies a reference to some object external to the specification. All explicit attributes shall be specified. The explicit attributes for this type are:

identifier

The attribute value shall be a string. It shall be the type-specific identifier of the referenced object. For group references use the Doxygen group identifier. For file references use a file system path to the file.

type

The attribute value shall be a Name. It shall be the type of the referenced object.

This type is refined by the following types:

This type is used by the following types:

5.2.3.46. Generic External Reference#

This type refines the following types:

It specifies a reference to an object of the specified type.

5.2.3.48. Integer or String#

A value of this type shall be of one of the following variants:

  • The value may be an integer number.

  • The value may be a string.

This type is used by the following types:

5.2.3.49. Interface Brief Description#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It shall be the brief description of the interface. It should be a single sentence. The value shall not match with the regular expression “\n\n”.

This type is used by the following types:

5.2.3.50. Interface Compound Definition Kind#

The value shall be a string. It specifies how the interface compound is defined. It may be a typedef only, the struct or union only, or a typedef with a struct or union definition. The value shall be an element of

  • struct-only”,

  • typedef-and-struct”,

  • typedef-and-union”,

  • typedef-only”, and

  • union-only”.

This type is used by the following types:

5.2.3.51. Interface Compound Member Compound#

This type refines the following types:

This set of attributes specifies an interface compound member compound. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be a list. Each list element shall be an Interface Compound Member Definition Directive.

5.2.3.52. Interface Compound Member Declaration#

This type refines the Interface Compound Member Definition through the kind attribute if the value is member. This set of attributes specifies an interface compound member declaration. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be a string. It shall be the interface compound member declaration. On the declaration a context-sensitive substitution of item variables is performed.

5.2.3.53. Interface Compound Member Definition#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes specifies an interface compound member definition. All explicit attributes shall be specified. The explicit attributes for this type are:

    brief

    The attribute value shall be an Interface Brief Description.

    description

    The attribute value shall be an Interface Description.

    kind

    The attribute value shall be a string. It shall be the interface compound member kind.

    name

    The attribute value shall be a string. It shall be the interface compound member name.

  • There may be no value (null).

This type is refined by the following types:

This type is used by the following types:

5.2.3.54. Interface Compound Member Definition Directive#

This set of attributes specifies an interface compound member definition directive. All explicit attributes shall be specified. The explicit attributes for this type are:

default

The attribute value shall be an Interface Compound Member Definition. The default definition will be used if no variant-specific definition is enabled.

variants

The attribute value shall be a list. Each list element shall be an Interface Compound Member Definition Variant.

This type is used by the following types:

5.2.3.55. Interface Compound Member Definition Variant#

This set of attributes specifies an interface compound member definition variant. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be an Interface Compound Member Definition. The definition will be used if the expression defined by the enabled-by attribute evaluates to true. In generated header files, the expression is evaluated by the C preprocessor.

enabled-by

The attribute value shall be an Interface Enabled-By Expression.

This type is used by the following types:

5.2.3.56. Interface Definition#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It shall be the definition. On the definition a context-sensitive substitution of item variables is performed.

This type is used by the following types:

5.2.3.57. Interface Definition Directive#

This set of attributes specifies an interface definition directive. All explicit attributes shall be specified. The explicit attributes for this type are:

default

The attribute value shall be an Interface Definition. The default definition will be used if no variant-specific definition is enabled.

variants

The attribute value shall be a list. Each list element shall be an Interface Definition Variant.

This type is used by the following types:

5.2.3.58. Interface Definition Variant#

This set of attributes specifies an interface definition variant. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be an Interface Definition. The definition will be used if the expression defined by the enabled-by attribute evaluates to true. In generated header files, the expression is evaluated by the C preprocessor.

enabled-by

The attribute value shall be an Interface Enabled-By Expression.

This type is used by the following types:

5.2.3.59. Interface Description#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It shall be the description of the interface. The description should be short and concentrate on the average case. All special cases, usage notes, constraints, error conditions, configuration dependencies, references, etc. should be described in the Interface Notes.

This type is used by the following types:

5.2.3.60. Interface Enabled-By Expression#

A value of this type shall be an expression which defines under which conditions an interface definition is enabled. In generated header files, the expression is evaluated by the C preprocessor.

A value of this type shall be of one of the following variants:

  • The value may be a boolean. It is converted to 0 or 1. It defines a symbol in the expression.

  • The value may be a set of attributes. Each attribute defines an operator. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

    and

    The attribute value shall be a list. Each list element shall be an Interface Enabled-By Expression. The and operator defines a logical and of the expressions in the list.

    not

    The attribute value shall be an Interface Enabled-By Expression. The not operator defines a logical not of the expression.

    or

    The attribute value shall be a list. Each list element shall be an Interface Enabled-By Expression. The or operator defines a logical or of the expressions in the list.

  • The value may be a list. Each list element shall be an Interface Enabled-By Expression. It defines a logical or of the expressions in the list.

  • The value may be a string. It defines a symbol in the expression.

This type is used by the following types:

5.2.3.61. Interface Enum Definition Kind#

The value shall be a string. It specifies how the enum is defined. It may be a typedef only, the enum only, or a typedef with an enum definition. The value shall be an element of

  • enum-only”,

  • typedef-and-enum”, and

  • typedef-only”.

This type is used by the following types:

5.2.3.64. Interface Function or Macro Definition#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes specifies a function definition. All explicit attributes shall be specified. The explicit attributes for this type are:

    attributes

    The attribute value shall be an optional string. If the value is present, then it shall be the function attributes. On the attributes a context-sensitive substitution of item variables is performed. A function attribute is for example the indication that the function does not return to the caller.

    body

    The attribute value shall be an optional string. If the value is present, then it shall be the definition of a static inline function. On the function definition a context-sensitive substitution of item variables is performed. If no value is present, then the function is declared as an external function.

    params

    The attribute value shall be a list of strings. It shall be the list of parameter declarations of the function. On the function parameter declarations a context-sensitive substitution of item variables is performed.

    return

    The attribute value shall be an optional string. If the value is present, then it shall be the function return type. On the return type a context-sensitive substitution of item variables is performed.

  • There may be no value (null).

This type is used by the following types:

5.2.3.65. Interface Function or Macro Definition Directive#

This set of attributes specifies a function or macro definition directive. All explicit attributes shall be specified. The explicit attributes for this type are:

default

The attribute value shall be an Interface Function or Macro Definition. The default definition will be used if no variant-specific definition is enabled.

variants

The attribute value shall be a list. Each list element shall be an Interface Function or Macro Definition Variant.

This type is used by the following types:

5.2.3.66. Interface Function or Macro Definition Variant#

This set of attributes specifies a function or macro definition variant. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be an Interface Function or Macro Definition. The definition will be used if the expression defined by the enabled-by attribute evaluates to true. In generated header files, the expression is evaluated by the C preprocessor.

enabled-by

The attribute value shall be an Interface Enabled-By Expression.

This type is used by the following types:

5.2.3.67. Interface Group Identifier#

The value shall be a string. It shall be the identifier of the interface group. The value shall match with the regular expression “^[A-Z][a-zA-Z0-9]*$”.

This type is used by the following types:

5.2.3.71. Interface Notes#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It shall be the notes for the interface.

This type is used by the following types:

5.2.3.72. Interface Parameter#

This set of attributes specifies an interface parameter. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be an Interface Description.

dir

The attribute value shall be an Interface Parameter Direction.

name

The attribute value shall be a string. It shall be the interface parameter name.

This type is used by the following types:

5.2.3.73. Interface Parameter Direction#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It specifies the interface parameter direction. The value shall be an element of

    • in”,

    • out”, and

    • inout”.

This type is used by the following types:

5.2.3.75. Interface Return Directive#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes specifies an interface return. All explicit attributes shall be specified. The explicit attributes for this type are:

    return

    The attribute value shall be an optional string. It shall describe the interface return for unspecified return values.

    return-values

    The attribute value shall be a list. Each list element shall be an Interface Return Value.

  • There may be no value (null).

This type is used by the following types:

5.2.3.76. Interface Return Value#

This set of attributes specifies an interface return value. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be an Interface Description.

value

The attribute value shall be a Boolean or Integer or String. It shall be the described interface return value.

This type is used by the following types:

5.2.3.79. Name#

The value shall be a string. A string is a valid name if it matches with the ^([a-z][a-z0-9-]*|SPDX-License-Identifier)$ regular expression.

This type is used by the following types:

5.2.3.80. Optional Floating-Point Number#

A value of this type shall be of one of the following variants:

  • The value may be a floating-point number.

  • There may be no value (null).

5.2.3.81. Optional Integer#

A value of this type shall be of one of the following variants:

  • The value may be an integer number.

  • There may be no value (null).

This type is used by the following types:

5.2.3.82. Optional String#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string.

5.2.3.86. Register Bits Definition#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes specifies a register bit field. Single bits are bit fields with a width of one. All explicit attributes shall be specified. The explicit attributes for this type are:

    brief

    The attribute value shall be an Interface Brief Description.

    description

    The attribute value shall be an Interface Description.

    name

    The attribute value shall be a string. It shall be the name of the register bit field.

    properties

    The attribute value shall be a list of strings. It shall be the list of bit field properties. Properties are for example if the bit field can be read or written, or an access has side-effects such as clearing a status.

    start

    The attribute value shall be an integer number. It shall be the start bit of the bit field. Bit 0 is the least-significant bit.

    width

    The attribute value shall be an integer number. It shall be the width in bits of the bit field.

  • There may be no value (null).

This type is used by the following types:

5.2.3.87. Register Bits Definition Directive#

This set of attributes specifies a register bits directive. All explicit attributes shall be specified. The explicit attributes for this type are:

default

The attribute value shall be a list. Each list element shall be a Register Bits Definition. The default definition will be used if no variant-specific definition is enabled.

variants

The attribute value shall be a list. Each list element shall be a Register Bits Definition Variant.

This type is used by the following types:

5.2.3.88. Register Bits Definition Variant#

This set of attributes specifies a register bits variant. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be a list. Each list element shall be a Register Bits Definition. The definition will be used if the expression defined by the enabled-by attribute evaluates to true. In generated header files, the expression is evaluated by the C preprocessor.

enabled-by

The attribute value shall be an Interface Enabled-By Expression.

This type is used by the following types:

5.2.3.89. Register Block Include Role#

This type refines the Link through the role attribute if the value is register-block-include. It defines the register block include role of links. Links of this role are used to build register blocks using other register blocks. All explicit attributes shall be specified. The explicit attributes for this type are:

name

The attribute value shall be a string. It shall be a name to identify the included register block within the item. The name shall be unique within the scope of the item links of this role and the SpecTypeRegisterList.

5.2.3.90. Register Block Member Definition#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes specifies a register block member definition. All explicit attributes shall be specified. The explicit attributes for this type are:

    count

    The attribute value shall be an integer number. It shall be the count of registers of the register block member.

    name

    The attribute value shall be a Register Name.

  • There may be no value (null).

This type is used by the following types:

5.2.3.91. Register Block Member Definition Directive#

This set of attributes specifies a register block member definition directive. All explicit attributes shall be specified. The explicit attributes for this type are:

default

The attribute value shall be a Register Block Member Definition. The default definition will be used if no variant-specific definition is enabled.

offset

The attribute value shall be an integer number. It shall be the address of the register block member relative to the base address of the register block.

variants

The attribute value shall be a list. Each list element shall be a Register Block Member Definition Variant.

This type is used by the following types:

5.2.3.92. Register Block Member Definition Variant#

This set of attributes specifies a register block member definition variant. All explicit attributes shall be specified. The explicit attributes for this type are:

definition

The attribute value shall be a Register Block Member Definition. The definition will be used if the expression defined by the enabled-by attribute evaluates to true. In generated header files, the expression is evaluated by the C preprocessor.

enabled-by

The attribute value shall be an Interface Enabled-By Expression.

This type is used by the following types:

5.2.3.93. Register Definition#

This set of attributes specifies a register. All explicit attributes shall be specified. The explicit attributes for this type are:

bits

The attribute value shall be a list. Each list element shall be a Register Bits Definition Directive.

brief

The attribute value shall be an Interface Brief Description.

description

The attribute value shall be an Interface Description.

name

The attribute value shall be a string. It shall be the name to identify the register definition. The name shall be unique within the scope of the Register Block Include Role links of the item and the SpecTypeRegisterList.

width

The attribute value shall be an integer number. It shall be the width of the register in bits.

In addition to the explicit attributes, generic attributes may be specified. Each generic attribute key shall be a Name. The attribute value may have any type.

This type is used by the following types:

5.2.3.94. Register Name#

The value shall be a string. The name consists either of an identifier, or an identifier and an alias. The identifier and alias are separated by a colon (:). The identifier shall match with the name of a register definition of the item (see Register Definition) or the name of a register block include of the item (see Register Block Include Role). If no alias is specified, then the identifier is used for the register block member name, otherwise the alias is used. If the register block member names are not unique within the item, then a postfix number is appended to the names. The number starts with zero for each set of names. The value shall match with the regular expression “^[a-zA-Z_][a-zA-Z0-9_]*(:[a-zA-Z_][a-zA-Z0-9_]*)?$”.

This type is used by the following types:

5.2.3.95. Requirement Design Group Identifier#

A value of this type shall be of one of the following variants:

  • There may be no value (null).

  • The value may be a string. It shall be the identifier of the requirement design group. The value shall match with the regular expression “^[a-zA-Z0-9_]*$”.

This type is used by the following types:

5.2.3.97. Requirement Text#

The value shall be a string. It shall state a requirement or constraint. The text should not use one of the following words or phrases:

  • acceptable

  • adequate

  • almost always

  • and/or

  • appropriate

  • approximately

  • as far as possible

  • as much as practicable

  • best

  • best possible

  • easy

  • efficient

  • e.g.

  • enable

  • enough

  • etc.

  • few

  • first rate

  • flexible

  • generally

  • goal

  • graceful

  • great

  • greatest

  • ideally

  • i.e.

  • if possible

  • in most cases

  • large

  • many

  • maximize

  • minimize

  • most

  • multiple

  • necessary

  • numerous

  • optimize

  • ought to

  • probably

  • quick

  • rapid

  • reasonably

  • relevant

  • robust

  • satisfactory

  • several

  • shall be included but not limited to

  • simple

  • small

  • some

  • state of the art

  • sufficient

  • suitable

  • support

  • systematically

  • transparent

  • typical

  • user friendly

  • usually

  • versatile

  • when necessary

This type is used by the following types:

5.2.3.99. Runtime Measurement Environment Name#

The value shall be a string. It specifies the runtime measurement environment name. The value

  • shall be an element of

    • FullCache”,

    • HotCache”, and

    • DirtyCache”,

  • or, shall match with the regular expression “^Load/[1-9][0-9]*$”.

This type is used by the following types:

5.2.3.100. Runtime Measurement Environment Table#

This set of attributes provides runtime performance limits for a set of runtime measurement environments. Generic attributes may be specified. Each generic attribute key shall be a Runtime Measurement Environment Name. Each generic attribute value shall be a Runtime Measurement Value Table.

This type is used by the following types:

5.2.3.101. Runtime Measurement Parameter Set#

This set of attributes defines parameters of the runtime measurement test case. All explicit attributes shall be specified. The explicit attributes for this type are:

sample-count

The attribute value shall be an integer number. It shall be the sample count of the runtime measurement context.

In addition to the explicit attributes, generic attributes may be specified. Each generic attribute key shall be a Name. The attribute value may have any type.

This type is used by the following types:

5.2.3.103. Runtime Measurement Value Kind#

The value shall be a string. It specifies the kind of a runtime measurement value. The value shall be an element of

  • max-lower-bound”,

  • max-upper-bound”,

  • mean-lower-bound”,

  • mean-upper-bound”,

  • median-lower-bound”,

  • median-upper-bound”,

  • min-lower-bound”, and

  • min-upper-bound”.

This type is used by the following types:

5.2.3.104. Runtime Measurement Value Table#

This set of attributes provides a set of runtime measurement values each of a specified kind. The unit of the values shall be one second. Generic attributes may be specified. Each generic attribute key shall be a Runtime Measurement Value Kind. Each generic attribute value shall be a floating-point number.

This type is used by the following types:

5.2.3.105. Runtime Performance Parameter Set#

This set of attributes defines parameters of the runtime performance requirement. Generic attributes may be specified. Each generic attribute key shall be a Name. The attribute value may have any type.

This type is used by the following types:

5.2.3.106. SHA256 Hash Value#

The value shall be a string. It shall be a SHA256 hash value encoded in base64url. The value shall match with the regular expression “^[A-Za-z0-9+_=-]{44}$”.

This type is used by the following types:

5.2.3.107. SPDX License Identifier#

The value shall be a string. It defines the license of the item expressed though an SPDX License Identifier. The value

  • shall be equal to “CC-BY-SA-4.0 OR BSD-2-Clause”,

  • or, shall be equal to “BSD-2-Clause”,

  • or, shall be equal to “CC-BY-SA-4.0”.

This type is used by the following types:

5.2.3.108. Specification Attribute Set#

This set of attributes specifies a set of attributes. The following explicit attributes are mandatory:

  • attributes

  • description

  • mandatory-attributes

The explicit attributes for this type are:

attributes

The attribute value shall be a Specification Explicit Attributes. It shall specify the explicit attributes of the attribute set.

description

The attribute value shall be an optional string. It shall be the description of the attribute set.

generic-attributes

The attribute value shall be a Specification Generic Attributes. It shall specify the generic attributes of the attribute set.

mandatory-attributes

The attribute value shall be a Specification Mandatory Attributes. It shall specify the mandatory attributes of the attribute set.

This type is used by the following types:

5.2.3.109. Specification Attribute Value#

This set of attributes specifies an attribute value. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be an optional string. It shall be the description of the attribute value.

spec-type

The attribute value shall be a Name. It shall be the specification type of the attribute value.

This type is used by the following types:

5.2.3.110. Specification Boolean Value#

This attribute set specifies a boolean value. Only the description attribute is mandatory. The explicit attributes for this type are:

assert

The attribute value shall be a boolean. This optional attribute defines the value constraint of the specified boolean value. If the value of the assert attribute is true, then the value of the specified boolean value shall be true. If the value of the assert attribute is false, then the value of the specified boolean value shall be false. In case the assert attribute is not present, then the value of the specified boolean value may be true or false.

description

The attribute value shall be an optional string. It shall be the description of the specified boolean value.

This type is used by the following types:

5.2.3.111. Specification Explicit Attributes#

Generic attributes may be specified. Each generic attribute key shall be a Name. Each generic attribute value shall be a Specification Attribute Value. Each generic attribute specifies an explicit attribute of the attribute set. The key of the each generic attribute defines the attribute key of the explicit attribute.

This type is used by the following types:

5.2.3.112. Specification Floating-Point Assert#

A value of this type shall be an expression which asserts that the floating-point value of the specified attribute satisfies the required constraints.

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. Each attribute defines an operator. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

    and

    The attribute value shall be a list. Each list element shall be a Specification Floating-Point Assert. The and operator evaluates to the logical and of the evaluation results of the expressions in the list.

    eq

    The attribute value shall be a floating-point number. The eq operator evaluates to true, if the value to check is equal to the value of this attribute, otherwise to false.

    ge

    The attribute value shall be a floating-point number. The ge operator evaluates to true, if the value to check is greater than or equal to the value of this attribute, otherwise to false.

    gt

    The attribute value shall be a floating-point number. The gt operator evaluates to true, if the value to check is greater than the value of this attribute, otherwise to false.

    le

    The attribute value shall be a floating-point number. The le operator evaluates to true, if the value to check is less than or equal to the value of this attribute, otherwise to false.

    lt

    The attribute value shall be a floating-point number. The lt operator evaluates to true, if the value to check is less than the value of this attribute, otherwise to false.

    ne

    The attribute value shall be a floating-point number. The ne operator evaluates to true, if the value to check is not equal to the value of this attribute, otherwise to false.

    not

    The attribute value shall be a Specification Floating-Point Assert. The not operator evaluates to the logical not of the evaluation results of the expression.

    or

    The attribute value shall be a list. Each list element shall be a Specification Floating-Point Assert. The or operator evaluates to the logical or of the evaluation results of the expressions in the list.

  • The value may be a list. Each list element shall be a Specification Floating-Point Assert. This list of expressions evaluates to the logical or of the evaluation results of the expressions in the list.

This type is used by the following types:

5.2.3.113. Specification Floating-Point Value#

This set of attributes specifies a floating-point value. Only the description attribute is mandatory. The explicit attributes for this type are:

assert

The attribute value shall be a Specification Floating-Point Assert. This optional attribute defines the value constraints of the specified floating-point value. In case the assert attribute is not present, then the value of the specified floating-point value may be every valid floating-point number.

description

The attribute value shall be an optional string. It shall be the description of the specified floating-point value.

This type is used by the following types:

5.2.3.114. Specification Generic Attributes#

This set of attributes specifies generic attributes. Generic attributes are attributes which are not explicitly specified by Specification Explicit Attributes. They are restricted to uniform attribute key and value types. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be an optional string. It shall be the description of the generic attributes.

key-spec-type

The attribute value shall be a Name. It shall be the specification type of the generic attribute keys.

value-spec-type

The attribute value shall be a Name. It shall be the specification type of the generic attribute values.

This type is used by the following types:

5.2.3.115. Specification Information#

This set of attributes specifies attribute values. At least one of the explicit attributes shall be specified. The explicit attributes for this type are:

bool

The attribute value shall be a Specification Boolean Value. It shall specify a boolean value.

dict

The attribute value shall be a Specification Attribute Set. It shall specify a set of attributes.

float

The attribute value shall be a Specification Floating-Point Value. It shall specify a floating-point value.

int

The attribute value shall be a Specification Integer Value. It shall specify an integer value.

list

The attribute value shall be a Specification List. It shall specify a list of attributes or values.

none

The attribute shall have no value. It specifies that no value is required.

str

The attribute value shall be a Specification String Value. It shall specify a string.

This type is used by the following types:

5.2.3.116. Specification Integer Assert#

A value of this type shall be an expression which asserts that the integer value of the specified attribute satisfies the required constraints.

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. Each attribute defines an operator. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

    and

    The attribute value shall be a list. Each list element shall be a Specification Integer Assert. The and operator evaluates to the logical and of the evaluation results of the expressions in the list.

    eq

    The attribute value shall be an integer number. The eq operator evaluates to true, if the value to check is equal to the value of this attribute, otherwise to false.

    ge

    The attribute value shall be an integer number. The ge operator evaluates to true, if the value to check is greater than or equal to the value of this attribute, otherwise to false.

    gt

    The attribute value shall be an integer number. The gt operator evaluates to true, if the value to check is greater than the value of this attribute, otherwise to false.

    le

    The attribute value shall be an integer number. The le operator evaluates to true, if the value to check is less than or equal to the value of this attribute, otherwise to false.

    lt

    The attribute value shall be an integer number. The lt operator evaluates to true, if the value to check is less than the value of this attribute, otherwise to false.

    ne

    The attribute value shall be an integer number. The ne operator evaluates to true, if the value to check is not equal to the value of this attribute, otherwise to false.

    not

    The attribute value shall be a Specification Integer Assert. The not operator evaluates to the logical not of the evaluation results of the expression.

    or

    The attribute value shall be a list. Each list element shall be a Specification Integer Assert. The or operator evaluates to the logical or of the evaluation results of the expressions in the list.

  • The value may be a list. Each list element shall be a Specification Integer Assert. This list of expressions evaluates to the logical or of the evaluation results of the expressions in the list.

This type is used by the following types:

5.2.3.117. Specification Integer Value#

This set of attributes specifies an integer value. Only the description attribute is mandatory. The explicit attributes for this type are:

assert

The attribute value shall be a Specification Integer Assert. This optional attribute defines the value constraints of the specified integer value. In case the assert attribute is not present, then the value of the specified integer value may be every valid integer number.

description

The attribute value shall be an optional string. It shall be the description of the specified integer value.

This type is used by the following types:

5.2.3.118. Specification List#

This set of attributes specifies a list of attributes or values. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be an optional string. It shall be the description of the list.

spec-type

The attribute value shall be a Name. It shall be the specification type of elements of the list.

This type is used by the following types:

5.2.3.119. Specification Mandatory Attributes#

It defines which explicit attributes are mandatory.

A value of this type shall be of one of the following variants:

  • The value may be a list. Each list element shall be a Name. The list defines the mandatory attributes through their key names.

  • The value may be a string. It defines how many explicit attributes are mandatory. If none is used, then none of the explicit attributes is mandatory, they are all optional. The value shall be an element of

    • all”,

    • at-least-one”,

    • at-most-one”,

    • exactly-one”, and

    • none”.

This type is used by the following types:

5.2.3.122. Specification String Assert#

A value of this type shall be an expression which asserts that the string of the specified attribute satisfies the required constraints.

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. Each attribute defines an operator. Exactly one of the explicit attributes shall be specified. The explicit attributes for this type are:

    and

    The attribute value shall be a list. Each list element shall be a Specification String Assert. The and operator evaluates to the logical and of the evaluation results of the expressions in the list.

    contains

    The attribute value shall be a list of strings. The contains operator evaluates to true, if the string to check converted to lower case with all white space characters converted to a single space character contains a string of the list of strings of this attribute, otherwise to false.

    eq

    The attribute value shall be a string. The eq operator evaluates to true, if the string to check is equal to the value of this attribute, otherwise to false.

    ge

    The attribute value shall be a string. The ge operator evaluates to true, if the string to check is greater than or equal to the value of this attribute, otherwise to false.

    gt

    The attribute value shall be a string. The gt operator evaluates to true, if the string to check is greater than the value of this attribute, otherwise to false.

    in

    The attribute value shall be a list of strings. The in operator evaluates to true, if the string to check is contained in the list of strings of this attribute, otherwise to false.

    le

    The attribute value shall be a string. The le operator evaluates to true, if the string to check is less than or equal to the value of this attribute, otherwise to false.

    lt

    The attribute value shall be a string. The lt operator evaluates to true, if the string to check is less than the value of this attribute, otherwise to false.

    ne

    The attribute value shall be a string. The ne operator evaluates to true, if the string to check is not equal to the value of this attribute, otherwise to false.

    not

    The attribute value shall be a Specification String Assert. The not operator evaluates to the logical not of the evaluation results of the expression.

    or

    The attribute value shall be a list. Each list element shall be a Specification String Assert. The or operator evaluates to the logical or of the evaluation results of the expressions in the list.

    re

    The attribute value shall be a string. The re operator evaluates to true, if the string to check matches with the regular expression of this attribute, otherwise to false.

    uid

    The attribute shall have no value. The uid operator evaluates to true, if the string is a valid UID, otherwise to false.

  • The value may be a list. Each list element shall be a Specification String Assert. This list of expressions evaluates to the logical or of the evaluation results of the expressions in the list.

This type is used by the following types:

5.2.3.123. Specification String Value#

This set of attributes specifies a string. Only the description attribute is mandatory. The explicit attributes for this type are:

assert

The attribute value shall be a Specification String Assert. This optional attribute defines the constraints of the specified string. In case the assert attribute is not present, then the specified string may be every valid string.

description

The attribute value shall be an optional string. It shall be the description of the specified string attribute.

This type is used by the following types:

5.2.3.124. Test Case Action#

This set of attributes specifies a test case action. All explicit attributes shall be specified. The explicit attributes for this type are:

action-brief

The attribute value shall be an optional string. It shall be the test case action brief description.

action-code

The attribute value shall be a string. It shall be the test case action code.

checks

The attribute value shall be a list. Each list element shall be a Test Case Check.

links

The attribute value shall be a list. Each list element shall be a Link. The links should use the Requirement Validation Link Role for validation tests and the Unit Test Link Role for unit tests.

This type is used by the following types:

5.2.3.125. Test Case Check#

This set of attributes specifies a test case check. All explicit attributes shall be specified. The explicit attributes for this type are:

brief

The attribute value shall be an optional string. It shall be the test case check brief description.

code

The attribute value shall be a string. It shall be the test case check code.

links

The attribute value shall be a list. Each list element shall be a Link. The links should use the Requirement Validation Link Role for validation tests and the Unit Test Link Role for unit tests.

This type is used by the following types:

5.2.3.126. Test Context Member#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes defines an action requirement test context member. All explicit attributes shall be specified. The explicit attributes for this type are:

    brief

    The attribute value shall be an optional string. It shall be the test context member brief description.

    description

    The attribute value shall be an optional string. It shall be the test context member description.

    member

    The attribute value shall be a string. It shall be the test context member definition. It shall be a valid C structure member definition without a trailing ;.

  • There may be no value (null).

This type is used by the following types:

5.2.3.127. Test Header#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes specifies a test header. In case a test header is specified, then instead of a test case a test run function will be generated. The test run function will be declared in the test header target file and defined in the test source target file. The test run function can be used to compose test cases. The test header file is not automatically included in the test source file. It should be added to the includes or local includes of the test. All explicit attributes shall be specified. The explicit attributes for this type are:

    code

    The attribute value shall be an optional string. If the value is present, then it shall be the test header code. The header code is placed at file scope after the general test declarations and before the test run function declaration.

    freestanding

    The attribute value shall be a boolean. The value shall be true, if the test case is freestanding, otherwise false. Freestanding test cases are not statically registered. Instead the generated test runner uses T_case_begin() and T_case_end().

    includes

    The attribute value shall be a list of strings. It shall be a list of header files included by the header file via #include <...>.

    local-includes

    The attribute value shall be a list of strings. It shall be a list of header files included by the header file via #include "...".

    run-params

    The attribute value shall be a list. Each list element shall be a Test Run Parameter.

    target

    The attribute value shall be a string. It shall be the path to the generated test header file.

  • There may be no value (null).

This type is used by the following types:

5.2.3.128. Test Run Parameter#

This set of attributes specifies a parameter for the test run function. In case this parameter is used in an Action Requirement Item Type item, then the parameter is also added as a member to the test context, see Test Context Member. All explicit attributes shall be specified. The explicit attributes for this type are:

description

The attribute value shall be a string. It shall be the description of the parameter.

dir

The attribute value shall be an Interface Parameter Direction.

name

The attribute value shall be a string. It shall be the parameter name.

specifier

The attribute value shall be a string. It shall be the complete function parameter specifier. Use ${.:name} for the parameter name, for example "int ${.:name}".

This type is used by the following types:

5.2.3.129. Test Support Method#

A value of this type shall be of one of the following variants:

  • The value may be a set of attributes. This set of attributes defines an action requirement test support method. All explicit attributes shall be specified. The explicit attributes for this type are:

    brief

    The attribute value shall be an optional string. It shall be the test support method brief description.

    code

    The attribute value shall be a string. It shall be the test support method code. The code may use a local variable ctx which points to the test context, see Test Context Member.

    description

    The attribute value shall be an optional string. It shall be the test support method description.

  • There may be no value (null).

This type is used by the following types:

5.2.3.130. UID#

The value shall be a string. The string shall be a valid absolute or relative item UID.

This type is used by the following types:

5.3. Traceability of Specification Items#

The standard ECSS-E-ST-10-06C demands that requirements shall be under configuration management, backwards-traceable and forward-traceable [ECS09]. Requirements are a specialization of specification items in RTEMS.

5.3.1. History of Specification Items#

The RTEMS specification items should placed in the RTEMS sources using Git for version control. The history of specification items can be traced with Git. Special commit procedures for changes in specification item files should be established. For example, it should be allowed to change only one specification item per commit. A dedicated Git commit message format may be used as well, e.g. use of Approved-by: or Reviewed-by: lines which indicate an agreed statement (similar to the Linux kernel patch submission guidelines). Git commit procedures may be ensured through a server-side pre-receive hook. The history of requirements may be also added to the specification items directly in a revision attribute. This would make it possible to generate the history information for documents without having the Git repository available, e.g. from an RTEMS source release archive.

5.3.2. Backward Traceability of Specification Items#

Providing backward traceability of specification items means that we must be able to find the corresponding higher level specification item for each refined specification item. A custom tool needs to verify this.

5.3.3. Forward Traceability of Specification Items#

Providing forward traceability of specification items means that we must be able to find all the refined specification items for each higher level specification item. A custom tool needs to verify this. The links from parent to child specification items are implicitly defined by links from a child item to a parent item.

5.3.4. Traceability between Software Requirements, Architecture and Design#

The software requirements are implemented in custom YAML files, see Specification Items. The software architecture and design is written in Doxygen markup. Doxygen markup is used throughout all header and source files. A Doxygen filter program may be provided to place Doxygen markup in assembler files. The software architecture is documented via Doxygen groups. Each Doxygen group name should have a project-specific name and the name should be unique within the project, e.g. RTEMSTopLevelMidLevelLowLevel. The link from a Doxygen group to its parent group is realized through the @ingroup special command. The link from a Doxygen group or software component to the corresponding requirement is realized through a @satisfy{req} custom command which needs the identifier of the requirement as its one and only parameter. Only links to parents are explicitly given in the Doxygen markup. The links from a parent to its children are only implicitly specified via the link from a child to its parent. So, a tool must process all files to get the complete hierarchy of software requirements, architecture and design. Links from a software component to another software component are realized through automatic Doxygen references or the @ref and @see special commands.

5.4. Requirement Management#

5.4.1. Change Control Board#

Working with requirements usually involves a Change Control Board (CCB). The CCB of the RTEMS Project is the RTEMS developer mailing list.

There are the following actors involved:

  • RTEMS users: Everyone using the RTEMS real-time operating system to design, develop and build an application on top of it.

  • RTEMS developers: The persons developing and maintaining RTEMS. They write patches to add or modify code, requirements, tests and documentation.

Adding and changing requirements follows the normal patch review process. The normal patch review process is described in the RTEMS User Manual. Reviews and comments may be submitted by anyone, but a maintainer review is required to approve significant changes. In addition for significant changes, there should be at least one reviewer with a sufficient independence from the author which proposes a new requirement or a change of an existing requirement. Working in another company on different projects is sufficiently independent. RTEMS maintainers do not know all the details, so they trust in general people with experience on a certain platform. Sometimes no review comments may appear in a reasonable time frame, then an implicit agreement to the proposed changes is assumed. Patches can be sent at anytime, so controlling changes in RTEMS requires a permanent involvement on the RTEMS developer mailing list.

For a qualification of RTEMS according to certain standards, the requirements may be approved by an RTEMS user. The approval by RTEMS users is not the concern of the RTEMS Project, however, the RTEMS Project should enable RTEMS users to manage the approval of requirements easily. This information may be also used by a independent authority which comes into play with an Independent Software Verification and Validation (ISVV). It could be used to select a subset of requirements, e.g. look only at the ones approved by a certain user. RTEMS users should be able to reference the determinative content of requirements, test procedures, test cases and justification reports in their own documentation. Changes in the determinative content should invalidate all references to previous versions.

5.4.2. Add a Requirement#