Africa 
China 
Japan 
MENA 
Explore chapters and articles related to this topic
Standardized Basic System Software for Automotive Embedded Applications
Published in Richard Zurawski, Industrial Communication Technology Handbook, 2017
Ports are typed by a specific interface, where AUTOSAR defines the following types of interfaces: Sender–Receiver (S/R) Interfaces: Via a sender–receiver interface, a single sender distributes information to one or more receivers (1:n communication), or one receiver gets information from one or several senders (n:1 communication). The sender–receiver interface consists of data elements that define the data that are exchanged. The type of a data element can either be a simple data type (e.g., an integral value) or a complex data type (e.g., an array or a structure). The transfer of a single data element is hereby performed in an atomic fashion.Client–Server (C/S) Interfaces: Via a client–server interface, one or more clients can invoke a remote operation provided by a server (n:1 communication). The client–server interface consists of the operations that are provided by the server and can be invoked by the client. This operation invocation can either be synchronous (i.e., the client is blocked until the result of the operation is available) or asynchronous (the client is not blocked but asynchronously notified as soon as the result is available).Mode–Switch (M/S) Interfaces: Via a mode–switch interface, a mode manager publishes the current mode to one or more mode users (1:n communication) in order to have these mode users adjust their behavior according to the current mode or to synchronize activities to mode switches. The mode–switch interface consists of a so-called mode declaration group that is the aggregation of all distinct mode declarations (i.e., all different modes the mode manager can reside in).Parameter Interface: Via a parameter interface, a parameter SWC publishes constant data or calibration data. Similar to the S/R interface, the parameter interface consists of data elements that define the data that are provided.NV Data Interface: Via an NV data interface, an NV block SWC provides access to NV data on a fine-grained level. Similar to the S/R interface, the NV data interface consists of data elements that define the NV data that are provided.Trigger Interface: By means of a trigger interface, an SWC is capable of directly triggering the execution of the runnable entities (see Section 51.6.1.4) of other SWCs in order to facilitate fast responses to certain events.
Development and evaluation of MicroBuilder: a Model-Driven tool for the specification of REST Microservice Software Architectures
Published in Enterprise Information Systems, 2018
Branko Terzić, Vladimir Dimitrieski, Slavica Kordić, Gordana Milosavljević, Ivan Luković
The ‘User’ microservice will be listening for the user requests on 8081 HTTP port, and will be included into microservice auto-discovery configuration. This microservice comprises a set of three microservice entities: the ‘UserDetail’, the ‘PaymentDetail’ and the ‘User’ microservice entitie. The ‘UserDetail’ and ‘PaymentDetail’ microservice entity values should not be persisted within database, and they are only used to describe basic user information as well as user payment information. Thus, ‘UserDetail’and ‘PaymentDetail’ microservice entities are used to specify the complex data type attributes within the ‘User’ microservice entity attributes. The ‘User’ microservice REST API comprises four methods in charge of: (i) registration of new users, (ii) user login, (iii) checking if user is active for the given user identifier and (iv) retrieving the user payment details for the given user identifier.
An ontology-based multi-criteria decision support system to reconfigure manufacturing systems
Published in IISE Transactions, 2020
Mohammed M. Mabkhot, Sana Kouki Amri, Saber Darmoul, Ali M. Al-Samhan, Sabeur Elkosantini
Data acquired from the MES is analyzed in order to detect deviations and infer disturbances. In the ontology, an instance (CurrentEvent) is updated with data acquired from the MES. This instance is subject to reasoning and inferencing using the reasoner and predefined rules (cf. Section 5.2.2) to determine whether to tolerate the event or to consider it as a disturbance. For reasoning and inferencing, we use Pellet 2.2.0 because it has some required capabilities (such as complex data-type reasoning and support of SWRL rules) not present in other reasoners (Sirin et al., 2007).