Timing Contracts for Embedded System Architecture Verification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional design approaches for embedded systems, particularly in automotive applications, face challenges in verifying non-functional properties like timing-related aspects, due to system complexity and heterogeneity, which complicates integration, validation, and architecture design.

Innovation Solution

A method that generates architecture models with timing semantics and contracts, using formal specifications, to ensure software components and models satisfy timing requirements, allowing for static or run-time verification and iterative modification until compliance is achieved.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional design approaches and programming methods are used for embedded systems, then the system can be implemented with standard tools, but the correctness and timing-related properties cannot be verified

Engineering Contradiction:
Improveverification of timing propertiesVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the embedded system into heterogeneous models and components, each representing different aspects of the system (functional, architectural, timing). This segmentation allows formal verification methods to be applied to specific segments (models) rather than the entire complex system, making verification feasible while managing overall system complexity

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces formal specifications and contracts as intermediary elements between the embedded system implementation and verification. These contracts serve as mediators that formally define timing properties and constraints, enabling automated verification tools to check compliance without directly analyzing the entire complex system

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If model-based design approach is used to reduce system complexity and time to market, then development efficiency improves, but system integration and verification remain challenging due to heterogeneity of models and languages

Engineering Contradiction:
Improvetime to marketVSAvoidintegration complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent creates a universal framework that can handle multiple heterogeneous models and languages used in model-based design. The formal specification approach serves as a universal interface that can represent different models (functional, architectural, timing) in a unified manner, enabling integration and verification across diverse modeling approaches without requiring separate processes for each model type

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent transforms heterogeneous models with different languages and semantics into a standardized formal specification format. This parameter transformation allows models created with different tools and languages to be integrated and verified using the same formal methods, reducing integration complexity while maintaining the productivity benefits of model-based design

Inventive Principle:
Principle #35Parameter changes

3Reliability

If architecture design is performed to manage heterogeneous components, then system performance and safety improve, but timing verification at system-level becomes difficult

Engineering Contradiction:
Improvesafety and performanceVSAvoidtiming verification difficulty
Core Design Contradiction:
ReliabilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent performs preliminary formal specification of timing properties and constraints during the architecture design phase, before implementation. By defining timing contracts and formal specifications early in the design process, the system enables automated verification of timing properties at the architectural level, making it easier to detect and measure timing issues before they propagate to the implementation level

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS20160291938A1Timing-oriented and architecture-centric system design using contracts
Publication Date: 2016.10.06 TOYOTA JIDOSHA KK
  • US20160291938A1 patent drawing
  • US20160291938A1 patent drawing
  • US20160291938A1 patent drawing

AI summary

The method may include designing one or more software models for one or more software components to be included in an embedded system. The method may include collecting information from the one or more requirements, the one or more software components, and the one or more software models. The method may include generating one or more architecture models that describe an execution platform, physical constraints, non-functional constraints, and characteristics of the embedded system based on the collected information. The method may include determining timing semantics to be satisfied by execution of functions in the embedded system. The method may include generating, by an electronic device, contracts based on the one or more requirements, the one or more software components, the one or more software models, the one or more architecture models, and the timing semantics.