{'fraction_non_alphanumeric': 0.02054794520547945, 'fraction_numerical': 0.0, 'mean_word_length': 5.774834437086093, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
How Timing Interfaces in AUTOSAR can Improve Distributed Development of Real-Time Software

Through the envisioned AUTOSAR methodology, the integration of hardware and software components shall become simpler and more flexible than ever. But in addition to standardized functional APIs, this approach also needs interfaces for non-functional component properties, specifically timing. However, formalizing the required parameters and defining new methodological steps is not trivial. In this paper, we illustrate ideas to structure timing properties by means of hand-over points and timing contracts using realistic examples, and we show how scheduling analysis provides key information to parameterize the resulting timing interfaces. Finally, we derive (sufficiently dark) gray-box timing chain segments that can be communicated between OEMs and suppliers without loss of IP protection. The resulting models are a) compatible with the AUTOSAR software architecture definitions and b) fit into the envisioned methodology.