Toimialayhteisöt

 

1.1 Scope of prEN 1991-1-6 (1) prEN 1991-1-6 provides guidance and general rules on the determination of actions relevant for the design of buildings and civil engineering works, including geotechnical structures, for their execution stage. NOTE Actions for design during execution include those that only arise from execution activities and act during execution, termed construction actions (for example personnel and hand tools, auxiliary structures, equipment and elements used during execution), and others that are present during the service life of the completed structure (for example self-weight, wind, etc.) but which can act differently and/or have different values during execution. (2) prEN 1991-1-6 provides guidance and general rules for the determination of actions for the design of auxiliary structures, elements and equipment used during execution in case they are designed to the Eurocodes and not to other European Standards. NOTE Other European Standards (e.g. EN 12810, EN 12811, EN 12812) provide specific rules for certain types of auxiliary structures, equipment and elements used during execution. (3) prEN 1991-1-6 gives rules for buildings and bridges during execution to supplement the provisions in EN 1990. NOTE For combination rules for execution, see EN 1990. 1.2 Assumptions (1) The general assumptions given in EN 1990 apply. (2) The application of this document follows the limit state principle and is based on the partial factor method, unless explicitly prescribed differently. (3) The verification of buildings and civil engineering structures in transient design situations is undertaken in accordance with the Eurocodes, accounting for the interaction with any auxiliary structures, elements and/or equipment. (4) When using European product standards covering auxiliary structures, equipment and elements used during execution, it is assumed that the design basis, design requirements and, if provided, the safety and operational design limits specified in these product standards are taken into account. (5) Adequate planning, documentation, communication, control and supervision are provided during execution, involving all relevant parties. NOTE Execution of a structure can involve interaction between several parties from diverse engineering fields, responsible for the design, fabrication, transportation and execution of different subsystems used during the execution of a structure.

 

ISO 21813 specifies methods for the chemical analysis of fine high purity barium titanate powders used as the raw material for fine ceramics. ISO 21813 stipulates the determination methods of the barium, titanium, aluminium, cadmium, calcium, cobalt, dysprosium, iron, lead, magnesium, manganese, nickel, niobium, potassium, silicon, sodium, strontium, vanadium, zirconium, carbon, oxygen and nitrogen contents in high purity barium titanate powders. The barium and titanium contents, the major elements, are determined by using an acid decomposition-gravimetric method or an acid decomposition-inductively coupled plasma-optical emission spectrometry (ICP-OES) method. The aluminium, cadmium, calcium, chromium, cobalt, dysprosium, iron, lead, magnesium, manganese, nickel, niobium, potassium, silicon, strontium, vanadium and zirconium contents are simultaneously determined via an acid digestion-ICP-OES method. The nitrogen content is determined by using an inert gas fusion-thermal conductivity method, while that of oxygen is determined via an inert gas fusion-IR absorption spectrometry method. Finally, the carbon content is determined using a combustion-IR absorption spectrometry method or a combustion-conductometry method.

 

This document specifies tolerances on dimensions and shape for hot rolled uncoated narrow strip and cut lengths of non-alloy and alloy steel grades in accordance with Table 1. It is usually produced in thickness of 0,8 mm up to and including 16 mm and generally has a rolled width less than 600 mm but is also produced in rolled widths up to and including 720 mm. Hot-rolled narrow strip has a symmetrical thickness profile with tight crown tolerances and therefore cannot be compared to slit wide strip. This document also applies to hot-rolled strip for cold rolling. Table 1 — Field of application [...table not represented...] This document can also be used for other steels, e.g.: steels from standards not mentioned in Table 1. This document does not apply to: — continuously hot-rolled wide strip and plate/sheet cut from wide strip of non-alloy and alloy steels and narrow strip obtained by slitting wide strip (EN 10051); — hot-rolled patterned steel strip and plate/sheet cut from wide strip (see EN 10363); — uncoated or electrolytically coated cold rolled sheet and strip (see EN 10131); — hot-dip coated steel sheet and strip (EN 10143).

 

 

This document specifies requirements for underground pipework systems used to transfer liquid fuels and their vapours at petrol filling stations. Minimum performance requirements covering fitness for purpose, safety and environmental protection are given. This document is applicable to pipework made from thermoplastics, which can include some degree of reinforcement, and to flexible metal pipework. It does not apply to fibre reinforced thermosets, commonly referred to as glass fibre reinforced plastic (GRP), nor to rigid metals. This document is applicable to: - delivery pipes from tanks to dispensers, including positive pressure, vacuum suction and siphon modes; - fill pipes from road tankers to tanks; - vapour recovery and vent pipework; - pipework for secondary containment; - fittings. It does not apply to pipework for use with liquefied petroleum gas.

 

This document defines the overall requirements and architecture for the communication system used to fuel gaseous hydrogen Vehicles. Since this document precedes industry applications it is written in the context of anticipated use. Specific systems may be given as examples, but applying the communication protocol is not limited to a particular system. The document includes requirements for the hardware, software, identification of Vehicle, communication structure, and integrity of the data. The communication protocol is intended to be capable of: Exchange of data for identifying the vehicle Exchange of data for the relevant parameters of its VFS Exchange of data for optimizing fuelling protocol Exchange of data in a safe and reliable manner This version of ISO 19885-2 does not include communications not directly related to the fuelling of Vehicle, such as payment methods. This document is intended to be used in conjunction with the family of ISO 19885 documents. It takes the general fuelling protocol requirements in ISO 19885-1 and adds communication specific requirements which would apply to all communications systems used in hydrogen fuelling. Example physical layers are included in the annex to provide guidance. Additional editions of ISO 19885 (e.g. 19885-3) will use this ISO 19885-2 to specify their communication systems for each fuelling protocol within their document.

 

This document specifies methods and criteria for assessing the general safety and environmental performance of road traffic noise reducing devices under typical roadside conditions. Appropriate test methods are provided where these are necessary. The treatment of each topic is covered separately in Annexes A to F.

 

This standard specifies the technical requirements for the control of environmental parameters in the whole process of spacecraft system level assembly, integration, and test. This standard is applicable to spacecraft system level assembly, integration, and test processes. This standard can serve as a reference for spacecrafts (e.g. commercial satellites) with more relaxed environmental requirements.

 

This document specifies test methods for the determination of strength, durability and stability of the structure of all types of seating without specific regard to end use, materials, design/construction or manufacturing process. This document does not apply to children’s highchairs, table mounted chairs and bath seats. Test methods for the assessment of ageing, degradation, ergonomics and electrical functions are not included. The test methods are not intended to assess the durability of upholstery materials.

 

This document specifies the communication interface between motion sensor and recording equipment. This includes mechanical, electrical and logical requirements.

 

This document specifies the reference software for carriage of haptics data as specified in ISO/IEC 23090-32. The information provided describes the reference software modules and the features that it supports. It also provides a description of how the reference software can be utilized. Finally, it also provides a description of conformance test vectors.

 

Warning The use of this International Standard may involve hazardous materials, operations and equipment. This International Standard does not purport to address all of the safety problems associated with its use. It is the responsibility of the user of this International Standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use. This International Standard gives specifications and operating instructions for glass capillary viscometers widely used for the determination of kinematic viscosity of petroleum products by the procedure described in ISO 3104. The calibration of these viscometers is also described. The types of viscometers described are modified Ostwald viscometers (Annex A), suspended-level viscometers (Annex B) and reverse-flow viscometers (Annex C). Other viscometers of the glass capillary type which are capable of measuring kinematic viscosity within the limits of precision given in ISO 3104 may be used.

 

Furthermore, this document, as amended by the corresponding amendment for Gaussian splat support, also specifies the use of the visual volumetric video-based coding mechanism for 3D scenes represented using Gaussian splat. In such representations, each point of the point cloud corresponds to a Gaussian primitive in 3D space and is described by a set of parameters, including at least its 3D position and additional attributes such as covariance, opacity and appearance coefficients. These parameters are mapped to geometry and attribute components within the V-PCC framework and coded using the same video-based mechanism. This enables efficient compression of Gaussian-splat-based scene representations and provides a coding solution suitable for Gaussian splat coding applications. 

 

This document specifies a method for the determination of total organic carbon (TOC) in water samples containing suspended solids (SS) in the range of 10 mg/l to 500 mg/l. The method includes the determination of particulate organic carbon using combined ultrasonic and alkaline extraction (CUAL) pretreatment and quantification by the difference between total carbon (TC) and total inorganic carbon (TIC). Typical matrices include wastewater, stormwater, leachates, and surface water.

 

The Kernel Modeling Language (KerML) is an application-independent modeling language with a well-grounded formal semantics for modeling existing or planned systems. The language includes general syntactic constructs for structuring models, such as relationships, annotations and namespaces; core semantic constructs that have semantics based on classification; and additional constructs for commonly needed modeling capabilities, such as associations and behaviors.

 

System models are expressed in KerML using a textual concrete syntax. This can be parsed to an abstract syntax representation, which is then given a semantic interpretation for the system being modeled. The semantics for the KerML core constructs is grounded in formal mathematical logic, providing a consistent basis for mathematical reasoning about KerML models. However, beyond this, the semantics of KerML constructs are specified by the relationship of user model elements to the KerML Semantic Library.

 

The Semantic Library models, also expressed in KerML, provide an ontological model of the meaning of KerML models. Indeed, all KerML models can be semantically expressed using solely core modeling constructs referencing the appropriate semantic concepts defined in the Semantic Library. KerML semantic constructs beyond the core are essentially just syntactic conveniences for reusing specific library concepts: structures for modeling objects, behaviors for modeling performances, associations for modeling links, etc.

 

Indeed, the full KerML language can be considered to be simply a syntactic extension of the core, which is semantically extended using library models. By intent, this approach can also be used to build on KerML to create more specific modeling languages. Application specific modeling languages can be built on KerML by extending the KerML abstract syntax, specializing its semantics, with concrete syntaxes similar to or entirely different from KerML's.

 

To support this, the KerML Semantic Library also includes additional library models beyond those directly providing semantics for KerML syntactic constructs, capturing typical semantic patterns (such as asynchronous transfers and state-based behavior) that can be reused by languages built on KerML. Specialized modeling languages can provide additional syntax for these libraries, tailored to their applications, with semantics based largely or entirely on the KerML libraries.

 

In this way, KerML can provide the kernel for a family of syntactically diverse but semantically integrated modeling languages.

 

The purpose of this standard is to specify the Systems Modeling Application Programming Interface (API) and Services that provide standard services to access, navigate, and operate on KerML-based models [KerML], and, in particular, SysML models [SysML]. The standard services facilitate interoperability both across SysML modeling environments and between SysML modeling environments and other engineering tools and enterprise services.

 

The Systems Modeling API and Services specifies the types and details of the requests that can be made and responses that can be received by software applications that are consuming the services to software applications that are providing the services.

 

The Systems Modeling API and Services specification includes the Platform Independent Model (PIM) - see Clause 7- and two Platform Specific Models (PSMs) - see Clause 8 : REST/HTTP PSM and OSLC PSM.

 

The purpose of this standard is to specify the Systems Modeling Language™ (SysML), to guide the implementation of conformant modeling tools, and to provide the basis for the development of material and other resources to train users in the application of SysML.

 

SysML is a general-purpose modeling language for modeling systems that is intended to facilitate a model-based systems engineering (MBSE) approach to engineer systems. It provides the capability to create and visualize models that represent many different aspects of a system. This includes representing the requirements, structure, and behavior of the system, and the specification of analysis cases and verification cases used to analyze and verify the system. The language is intended to support multiple systems engineering methods and practices. The specific methods and practices may impose additional constraints on how the language is used.

 

SysML is defined as an extension of the Kernel Modeling Language (KerML), which provides a common, domain independent language for building semantically rich and interoperable modeling languages. SysML also provides a capability to provide further language extensions. It is anticipated that SysML will be customized using this language extension mechanism to model more specialized domain-specific applications, such as automotive, aerospace, healthcare, and information systems, as well as discipline specific extensions such as safety and reliability.

 

Note. Definitions of system and systems engineering can be found in ISO/IEC 15288 Systems and Software Engineering – System Life Cycle Process.

 

This specification describes a transformation for a semantic translation from SysML v1 [SysMLv1] to SysML v2 [SysMLv2] in a precise way. (In this document, "SysML v1" refers to SysML v1.7, the last version of SysML prior to v2.0, and "SysML v2" refers to SysML v2.0, or whatever version corresponds to the current version of this specification.)

 

The main intent is to provide the rules on which automated conversions of SysML v1 models to the SysML v2 standard can be developed. In addition, this annex can be considered an educational document that provides useful information for people who would like to compare using SysML v2 and using SysML v1.

 

More sophisticated applications of this transformation can also be envisaged. For instance, a SysML v1 conformant tool could use this transformation to implement a limited subset of the SysML v2 API that will provide "SysMLv2-like" read-only access to its SysMLv1 models for external applications.

 

The Structured Patterns Metamodel Standard (SPMS) specification defines a common standard for the definition and description of patterns as used in architecting, designing, and implementing software systems, working with software faults or security issues, and any situation where a pattern is appropriately applied.

 

SPMS has three main goals:

1) Sharing of pattern definitions in repositories or catalogs, including human-oriented specifications and machine oriented formalisms for automated tool use.

2) Sharing of pattern instances – indicators of the existence of a pattern within a model – regardless of how that pattern was determined, with traceability back to the methodology, and traceability to the model artifacts that prove its existence. if applicable. These instances may come from manual assertion, or from the results of an automated tool.

3) A visual representation for pattern instances that augments existing modeling representations and supports both automated production of graphical diagrams, and informal “line and box” style human-generated sketching.

 

The first goal is supported by the Definitions package, which defines a metamodel for defining and storing pattern specifications, suitable for use in tooling and repositories.

 

The second goal is supported by the Observations package, which defines a metamodel for pattern instances. The classes defined here offer support for both human-oriented use cases (consulting, investigation, education) and machine oriented use cases (automated analysis tools, automated results analysis, etc.).

 

Both goals are further supported by the Relationships package, which augments the Definitions package with metadata appropriate for a repository or catalog of patterns. This metadata offers a set of semantic relationships between pattern definitions and instances, enhancing searchability and other use cases appropriate to the domain. Again, both human oriented and machine-oriented use cases are supported in this package.

 

The Formalisms package supports the first goal more thoroughly for automated tool use cases and research purposes. It provides a mechanism for linking to a variety of formal metamodels such as Object Constraint Language (OCL), Knowledge Domain Metamodel (KDM), Abstract Syntax Tree Metamodel (ASTM), or Pattern Hierarchical Object Relation Metamodel Language (PHORML), depending on the needs of the modeler and community.

 

The third goal is supported by the Pattern Instance Notation (PIN) metamodel, which defines a common metamodel for the graphical depiction of pattern instances. It relies on the abstractions defined in SPMS. PIN and the corresponding elements in SPMS are equivalent in their expressive power, and have a one-to-one coherence of features.

 

PIN was developed hand in hand with the Patterns package of SPMS and provides a simple and human-oriented approach for quickly depicting instances of patterns, how they work in concert, and how they are expressed in an implementation or further design document. Most notably, PIN can be used entirely by itself to illustrate pattern interactions independent of an implementation, or used as an annotation with the variety of other graphical notations, such as UML diagrams. 

 

This document specifies methodologies for measuring the performance of AI models for classification, regression, clustering and recommendation tasks.