shadazar
commented
7 years ago This text has been merged in to the document.
Closed DeOrellana closed 7 years ago
shadazar
commented
7 years ago This text has been merged in to the document.
Daniel Herring 2016-09-12 08:19:53 PDT
The SC version of the API should be a subset of the API in question. Allowing applications written for the SC version of the API to compile, link and function using a library/driver which provides the more general API.
This does not prevent addition of symbols (enumations) where needed.
Comment 1 Daniel Herring 2016-09-13 07:46:44 PDT
See email thread for reasons for changing to Guidelines vs Requirements.
Comment 2 Erik Noreke 2016-09-19 07:51:04 PDT
Accepted per call 2016-09-19
"Based on"
Don't change signature of duplicated functions.
Comment 3 Erik Noreke 2016-09-20 13:07:27 PDT
Setting QA contact to non-member SCAP mailing list.
Comment 4 Erik Noreke 2016-09-26 07:59:32 PDT
Assigning to Daniel per call 2016-09-26
Comment 5 illya@codeplay.com 2016-10-04 03:06:05 PDT
The 'size' of the API is I think irrelevant.SC API may be bigger than the general API due to extra testability required. Function signatures could also grow to accommodate for validation of state for example.
Comment 6 Daniel Herring 2016-10-31 12:52:06 PDT
Created attachment 4033 [details] The Profile Triangle
The shows a common profiling pyramid where the Desktop profile exists as the largest set of APIs, and an Embedded version may remove functionality and APIs which are not required in that profile. The Safety Critical version of the API is normally a smaller subset than the Embedded version of the API.
While it is desirable that the Safety Critical version of an API be a proper subset of the either the Desktop or Embedded profiles of the version, a Safety Critical API may need to also add functionality to the proper subset to achieve proper functionality within a safety critical environment.
Unlike many APIs which evolve at a rapid pace, adding new features, fixing issues or removing obsolete features, Safety Critical APIs exist for considerably longer, easily up to 20+ years. This is because it can easily take more than 5 years between the time a project is started and the hardware selected to the time that hardware makes it through safety certification and in to a production period which can easily last another 15 years. All the while the software for such hardware can be upgraded.
Long hardware prototype times, limited quantities, and specialized SC driver development makes it unrealistic to provide each developer access to hardware running an implementation of the Safety Critical version of an API. As such Safety Critical APIs should try be a subset of the Desktop Profile and common extensions of the API to allow developers to do 90% or more of their development and testing on compatible Desktop implementations of the API. This also allows the developers to use the multitude of tools the base API provides to debug, troubleshoot, and optimize.
Comment 7 Daniel Herring 2016-10-31 12:55:54 PDT
Created attachment 4034 [details] Profile Venn Diagram
This Venn Diagram shows that while the profile triangle is a general rule of thumb, that the different profiles may include additional APIs and functionality to meet the requirements of the specific profile. It also shows that the Safety Critical Core API Profile can include Desktop Extensions and is not limited to only the Desktop Core API.
Comment 8 Daniel Herring 2016-11-07 07:28:38 PST
If we keep the safety critical version of the API as a subset we do not introduce more IP than that which exists in the already ratified version of the standard. From a Khronos perspective this simplifies IP rights and ratification of the SC standard.
Comment 9 Erik Noreke 2016-11-07 07:56:05 PST
Per teleconference 2016-11-07 Illya to integrate into main document.