## 3 Problem Statement  
The objective of the A-HMI is to provide a substantial contribution to:  
* using all I/O on ADAS, IVIS, and nomadic devices safely;
* keeping driver's workload at a level that does not affect a safe driving performance;
* avoiding interference of multiple information sources;minimizing demanding interactions for the driver;
* decreasing the interaction complexity, according to the DVE state, via reconfiguration of the infotainment system;
* reducing response time for decision making. All these objectives are driven by the design of the IMS, which performs the management functions of the A-HMI, i.e., meta-functions responsible for managing ADAS, IVIS, and nomadic devices with respect to their interaction with the driver (e.g., the block on phone calls in demanding driving situations). The definition of the relevant driving scenarios is the first step for the IMS design, which, as already mentioned, is formalized using the actions and DVE conditions. The actions are classified into a set of five priority classes, as follows. * W: safety critical warnings (FCW, lane keeping, etc.). * D: system interaction, etc. * OP1: mandatory messages or important info related to the driving task (turn immediately notification, driver status, etc.). * OP2: temporary info related to the driving task, requiring an action in the near future (high engine temperature, low oil pressure, etc. ), or messages related to infotainment system. * OP3: permanent status info related to the driving task, not requiring an action in the near future, or output messages related to secondary tasks (incoming phone call, chat notification, etc.). Concerning the DVE conditions, as described in Section 2.1, they can be discretely represented by several parameters. The IMS decision-management process also takes into account the length of the actions' waiting queue through the parameter LQue, described as follows. * LQue \(\in\mathbb{B}=\{0,\,1\}\): queue state (\(0\)--Low, no waiting queue for message, notifications, indications, etc. ; 1--High, there is a waiting queue). When receiving a request vector from the applications with instruction about actions that have to be dispatched, the IMS applies in sequence:  
1. the strategy implemented in the Filter and Queue module, described in Section 2.2.1, that is based on truth tables describing prioritization rules for applications' requests as functions of DVE states;
2. the rules implemented in the Modality and Channel module, described in Section 2.2.2, which, too, are founded on truth tables containing criteria for selecting representation modality of messages, notifications, indications, etc. suited to DVE states. Therefore, to schedule output requests from the applications, and to select modality, channel, and layout for their presentation, a key task concerns the design of truth tables. This study proposes a methodology to derive truth tables for the Filter and Queue module, which can be easily extended to also define truth tables for the Modality and Channel module. A general formulation of a truth table is represented in Table 1 for scheduling actions (messages/notifications/indications to be forwarded to the driver) on the basis of \(n\in\mathbb{R}\) DVE parameters (DVE 1,..., DVE \(n\)), queue state (LQue), and \(m\in\mathbb{R}\) application requests (App. 1,..., App. \(m\)). More specifically, for prioritization purpose, action-specific logical expressions (truth functions) \(f_{i}(\text{DVE 1},\,\ldots,\,\text{DVE $n$, LQue, App. 1,..., App. $m$})\), with \(i\in\{1,\,\ldots,\,m\}\) the number of actions, sets out functional values in the Boolean domain \(f_{i}\in\mathbb{B}=\{0,\,1\}\) for each combination of truth values taken by the \(n+1+m\) variables (the arity of the function), i.e., DVE 1,..., DVE \(n\), LQue, App. 1,..., App. \(m\), which, too, are defined in the Boolean domain \(\mathbb{B}\). Through these functional values, the truth table, based on current DVE states, suggests if messages could be forwarded to the driver (value 1) or not (value 0).