VALICY safety envelope

In VALICY a safety envelope was introduced. The safety envelope, at the moment, is an area where only proper functioning of the application under test could be detected (all results "True"). We set it up for a certain local certainty, starting with 100 % for easier implementation. This certainty is different from the global certainty yielding one value for the hold problem input parameter range. The presence of also FALSE points must be evaluated by a local certainty value, which is challenging to implement at the time. But the result will allow export of all kinds of local certainties.

Local Certainty Calculation: Calculates local certainty within the safety envelope for specific input ranges, starting with 100%. Handling FALSE points is complex but essential for later stages.

Global Certainty Value: Provides a global certainty across the entire input parameter range, distinct from local certainty.

Detection of Proper Functioning: Automates the detection of correct application performance (all results TRUE), using both local and global certainty.

Local Certainty Export: Allows exporting different local certainties for further analysis and external use.

Adjustable Safety Envelope: Configurable for different testing scenarios and safety requirements, adaptable to the application's needs.

False Point Evaluation: A framework for assessing uncertain or faulty points (FALSE), improving the precision of local and global certainty measures.

These features ensure detailed monitoring and assessment of the application's performance within a controlled safety environment.

Public API Endpoints: Provide APIs for setting parameters, retrieving results, and exporting local certainties. These should be well-documented and support both synchronous (e.g., REST) and asynchronous (e.g., message queues) operations.

Microservices Architecture: For easier integration with modern applications, the safety envelope can be exposed as a microservice, using container platforms like Docker or Kubernetes for deployment and orchestration.

API Authentication: Implement secure API access via OAuth 2.0 or API keys to control who can interact with the safety envelope services.

Dependencies: Integration may require specific software libraries or frameworks to be compatible with the system, such as .NET, Java, or Python environments.

Version Compatibility: Ensure compatibility with specific versions of languages, APIs, and frameworks, particularly if interacting with older systems or platforms.

Testing Frameworks: Integrate with existing testing frameworks like JUnit, PyTest, or NUnit, to automate the evaluation of local and global certainties within the development lifecycle.

High-Performance Computing: For processing large datasets or complex calculations of local certainties, systems with high CPU and memory resources may be required.

Distributed Systems Support: The safety envelope should be capable of running on distributed or clustered systems to ensure scalability and fault tolerance.

These methods, requirements, and constraints aim to ensure flexible, secure, and efficient integration of the safety envelope into various testing and development environments.

The safety envelope targets the following customer groups:

1. QA Teams: Ensure software reliability and error detection during testing.
2. Mission-Critical Developers: Monitor performance in safety-critical systems (aerospace, medical, automotive).
3. Cloud Providers: Enhance reliability testing for distributed applications.
4. AI/ML Developers: Evaluate model performance and prediction certainty.
5. Cybersecurity Firms: Detect system anomalies and ensure security functionality.

These groups benefit from the safety envelope’s ability to monitor and assess performance across various input conditions.

licensing