Big Chemical Encyclopedia

Chemical substances, components, reactions, process design ...

Articles Figures Tables About

Embedded software

High-integrity design The precision of Catalysis specifications makes them suitable for the design of mission-critical systems and embedded software, where reliable design is an important issue. The rigor can be used in a variable manner. [Pg.65]

Embedded Software constitutes a very specific and critical part of embedded systems. It provides new capabilities to HW transducers ( defines physical behaviour of a complex non-linear device ), because of its potential criticality we need HW/SW co-design, and issues like dependability, low power, timeliness are becoming software issues with all the consequences. We need dependable system architectures to cope with the potential risks, including safety as well as security requirements and counter measures. Be aware, that security aspects are often neglected by safety engineers ... [Pg.164]

Leveson, Nancy, and Kathryn Weiss. Making embedded software reuse practical and safe. Foundations of Software Engineering, Newport Beach, Nov. 2004. [Pg.525]

A particular kind of embedded software is real-time software. This kind of software has requirements in terms of meeting time constraints. For example, the telephone software must play the dial tone within a certain time after the customer has taken the phone off hook. Often real-time systems are responsible for critical functions such as patient monitoring. In such cases special design techniques are needed to ensure correct operation within required time constraints. Real-time software is among the most challenging software to construct. [Pg.296]

We further specify which systems we model. Safety critical systems are systems that lead to hazardous events in case of failure (SommerviUe 2007 Wdliamson 1997). Embedded systems (Wolf 2002) and embedded software (Baier and Katoen 2008) can be foimd in the safety critical domain (Metzner 2006). As examples of safety critical systems airplanes, vehicles, power plants and chemical plants are mentioned in (Borcsok 2006 Borscok 2004). [Pg.1610]

The application software tests shall verify that all of the application software modules and com-ponents/subsystem interact correctly with each other and with underlying embedded software to perform their intended function and do not perform unintended functions. [Pg.258]

The integration of safety-related appHcation software into SRECS shall include tests that are specified during the design and development phase to ensure the compatibility of the appHcation software with hardware and embedded software platform such that the functional and safety performance requirements are satisfied. [Pg.259]

Hobbs, Chris, Embedded Software Development for Safety-Critical Systems, Auerbach Publications, Boca Raton, FL, 2015. [Pg.536]

In trying to relate IPR concepts and methods to the entire product lifecycle, it must be taken into account that, in general, patents are independent of any particular product and project. Therefore, patents must be maintained and defended as long as their subject has a commercial value for (potential) competitors. Product data in a project must be intensively protected from start of development (SoD) to start of production (SoP) and possibly less intensively afterwards (e.g., if they are created in a collaborative project that will be subsequently diminished). From the SoP until the end of a product life cycle (EoL), growing focus will be on the protection of products, spare parts and embedded software against possible counterfeits (Fig. 18.1). In that case reverse engineering (see Chap. 12) must be prevented or at least inhibited. [Pg.525]

Protection of embedded software is a key components of a holistic protection concept based on systems engineering approach [51] considering the complete security life cycle of products and services starting with requirements and finishing with decommissioning. [Pg.548]

Protection of products against plagiarism and counterfeits has been demonstrated on tangible and intangible products (embedded software). [Pg.548]

As the functionality and complexity of embedded software increases, more attention is being devoted to high level, abstract development methods. The Ada tasking model provides concurrency as a means of decoupling application activities, and hence making software easier to design and test (Vardanega van Katwijk 1999). [Pg.192]

NOTE 2 In the process sector, FVL is found in embedded software and rarely in application software. [Pg.38]

Utility software (together with the manufacturer safety manual which defines how the PE system can be safely applied) shall be selected and applied in conformance with the requirements of 12.4.4. The selection of embedded software shall comply with 11.5. [Pg.68]

Application software, the SIS hardware and embedded software and utility software (tools) shall be subject to configuration management (see 5.2.7). [Pg.70]

Generic and application specific features in hardware Examples include - diagnostic tests - redundant processors - dual I/O cards Embedded software Application software... [Pg.75]

Examples include - communications drivers - fault handling - executive software Exampies inciude - input/output functions - derived functions (for exampie sensor checking if not provided as a service of the embedded software)... [Pg.75]

The second objective of the requirements of this clause is to review and evaluate the requirements placed on the software by the hardware and embedded software architecture of the SIS. These include side-effects of the SIS hardware/software behaviour, the application specific configuration of SIS hardware, the inherent fault tolerance of the SIS and the interaction of the SIS hardware and embedded software architecture with the application software for safety. [Pg.77]

NOTE The selection of development tools should depend on the nature of the application software development activities, embedded software and the software architecture (see 12.4.3). [Pg.80]

The objective of this clause is to demonstrate that the application software meets its software safety requirements specification when running on the hardware and embedded software used in the SIS subsystem. [Pg.83]

Jackson, E.K., Sztipanovits, J. Using Separation of Concerns for Embedded Systems Design. In EMSOFT 2005 Proceedings of the 5th ACM International Conference on Embedded Software, pp. 25-34. ACM, New York (2005)... [Pg.69]

Are the SIS hardware, embedded software, and utility software under a formal revision and release control program ... [Pg.35]

Requirements placed on the software by the hardware and embedded software architecture of the SIS reviewed and evaluated -12.4.1.2... [Pg.71]

Demonstrate that the application software meets the software SRS when running on the SIS hardware and embedded software-12.5.1.1... [Pg.71]

See other pages where Embedded software is mentioned: [Pg.366]    [Pg.571]    [Pg.571]    [Pg.919]    [Pg.488]    [Pg.296]    [Pg.296]    [Pg.1329]    [Pg.525]    [Pg.547]    [Pg.249]    [Pg.262]    [Pg.17]    [Pg.38]    [Pg.38]    [Pg.61]    [Pg.63]    [Pg.68]    [Pg.69]    [Pg.66]    [Pg.67]    [Pg.72]    [Pg.75]    [Pg.75]   
See also in sourсe #XX -- [ Pg.212 ]



SEARCH



© 2024 chempedia.info