Supporting multiple levels of criticality

Totel, Éric; Blanquart, Jean-Paul; Deswarte, Yves; Powell, David

doi:10.1109/ftcs.1998.689456

Cited by 29 publications

(23 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The proposed contribution is based on an object-oriented, the SLO objects described levels of QoS and the MLO objects described levels of criticality of customers. In [24], the authors have specified that the MLO allow changing their level of criticality at any invocation method to control and accept data from lower or equal level. These objects have no memory, and are created at each invocation, which influences execution duration and reduces network performance; also, the identification of the exacted values for these thresholds is very difficult.…”

Section: Contribution and Discussionmentioning

confidence: 99%

“…It is based on objects classification in order to give a strict information flow to check integrity policy and to manipulate the mechanisms of information integrity upgrade. Authors in [24,25] defined three object types: Single Level Objects (SLOs): are single constant integrity level. This king contains information and creates flows using its internal data at different levels of integrity.…”

Section: Integrity Modelsmentioning

confidence: 99%

See 1 more Smart Citation

Multi Level Integrity Management in LTE/LTE-A Networks

Kasmi¹,

Baïna²,

Bellafkih³

2017

Adv. sci. technol. eng. syst. j.

View full text Add to dashboard Cite

Section: Contribution and Discussionmentioning

confidence: 99%

Section: Integrity Modelsmentioning

confidence: 99%

Multi Level Integrity Management in LTE/LTE-A Networks

Kasmi¹,

Baïna²,

Bellafkih³

2017

Adv. sci. technol. eng. syst. j.

View full text Add to dashboard Cite

“…The purpose of these objects is to output reliable information by using possibly corrupted data as input (i.e., with a low integrity level). Such objects upgrade the trustworthiness of data and hence allow information flows from low to high integrity levels [67].…”

Section: The Integrity Dimensionmentioning

confidence: 99%

GUARDS: a generic upgradable architecture for real-time dependable systems

Powell

Arlat

Beus-Dukic

et al. 1999

IEEE Trans. Parallel Distrib. Syst.

Self Cite

View full text Add to dashboard Cite

Abstract. The development and validation of fault-tolerant computers for critical realtime applications are currently both costly and time-consuming. Often, the underlying technology is out-of-date by the time the computers are ready for deployment. Obsolescence can become a chronic problem when the systems in which they are embedded have lifetimes of several decades. This paper gives an overview of the work carried out in a project that is tackling the issues of cost and rapid obsolescence by defining a generic fault-tolerant computer architecture based essentially on commercial off-the-shelf (COTS) components (both processor hardware boards and real-time operating systems). The architecture uses a limited number of specific, but generic, hardware and software components to implement an architecture that can be configured along three dimensions: redundant channels, redundant lanes and integrity levels. The two dimensions of physical redundancy allow the definition of a wide variety of instances with different fault-tolerance strategies. The integrity level dimension allows application components of different levels of criticality to co-exist in the same instance. The paper describes the main concepts of the architecture, the supporting environments for development and validation, and the prototypes currently being implemented.

show abstract

“…The systems presented in [11] and [16] can be implemented as iProve nuclei. The communication between a distributed system's nodes can be augmented with timingrelated properties by using [11].…”

Section: Related Workmentioning

confidence: 99%

“…The communication between a distributed system's nodes can be augmented with timingrelated properties by using [11]. In [16], on every method call, an integrity kernel checks if the caller object has the right to access the callee object, to prevent usage of untrusted data by critical parts of the system. The iProve join verifier is similar to ESP [4]; however, there are some important differences between the two.…”

Section: Related Workmentioning

confidence: 99%