METHOD FOR OPERATING A SAFETY CONTROLLER - TOOLCHAIN

Abstract

The present disclosure provides a safety-related engineering system that allows for the integration of non-safety-related software tools. A program file and a fingerprint object associated with the program file are also provided at an update time point. A consistency check between the program file and the fingerprint object is performed at a checking time point after the update time point. At a transfer time point after the checking time point, in case the consistency check confirmed a consistency between the program file and the fingerprint object, said program file is compiled and linked to obtain an executable program code, which executable program code is transferred to a memory of a safety controller and executed by means of at least one processor of said safety controller.

Claims

1. A method for operating a safety controller, which has a plurality of inputs configured to receive sensor signals, a plurality of outputs configured to output actuator signals, and at least one processor configured to execute program code, the method comprising: at an update time point, providing at least one program file and a fingerprint object associated with the program file, the program file defining logical dependencies between the sensor signals and the actuator signals, and the fingerprint object identifying the logical dependencies as provided at the update time point; at a checking time point after the update time point, performing a consistency check between the program file and fingerprint object; at a transfer time point after the checking time point, in case the consistency check confirmed a consistency between the program file and the fingerprint object; by a compiler, compiling and linking the program file to obtain an executable program code; transferring the executable program code to a memory of the safety controller; and executing the executable program code by means of the at least one processor, in order to generate the actuator signals as a function of the sensor signals.

2. The method according to claim 1, wherein a plurality of program files is provided at the update time point, each program file of the plurality of program files having an associated fingerprint object identifying the program file, and each program file being checked for consistency with its associated fingerprint object at the checking time point.

3. The method according to claim 2, wherein at least one program file of the plurality of program files is written in an open text format.

4. The method according to claim 2, wherein at least one program file of the plurality of program files is written in a limited variability language.

5. The method according to claim 1, wherein a fingerprint object of the provided fingerprint objects encompasses a description of the program file associated with the fingerprint object, thus allowing detection of a change of the program file associated with the fingerprint object, and/or of metadata of the program file, and/or of a date and/or time of a last change of the program file, and/or of a reference to a last valid version.

6. The method according to claim 1, wherein the fingerprint object allows detection of a change with a probability prescribed by the International Electrotechnical Commission (IEC) 61508 safety integrity level (SIL) 1 standard or by the by the IEC 61508 SIL 2 standard or by the by the IEC 61508 SIL 3 standard or by the by the IEC 61508 SIL 4 standard.

7. The method according to claim 1, wherein: in case the consistency check does not confirm a consistency between the program file and the fingerprint object, a warning to a user is provided and the generation of executable program code is stopped, in case the consistency check does not confirm a consistency between the program file and the fingerprint object, the at least one inconsistency between the program file and the fingerprint object leading to the consistency check not confirming a consistency between the program file and the fingerprint object is presented to a user and the user is given the opportunity to decide whether the generation of executable program code should be continued or stopped, or in case an inconsistency is detected, a list of changes between the program file and an associated back-up of the program file is provided.

8. The method according to claim 1, wherein: the consistency check is carried out by a method selected from the group consisting of cyclic redundancy check, Fletcher's checksum algorithm, one's complement addition, and two's compliment addition, and/or in addition to the consistency check, the program file is checked for compliance with a set of requirements resulting from a use case the program file is applied to.

9. The method according to claim 1, wherein at least one safety function is implemented in the program file.

10. The method according to claim 1, wherein: the program files process sensor signals generated by a safety sensor selected from the group consisting of light grids, light curtains, emergency stop buttons, safety limit switches, safety interlock switches, contactless safety magnetic switches, and contactless radio frequency identification (RFID) safety sensors, and the method further comprises creating an actuator signal according to the safety function.

11. A programming tool for programming a safety controller of a safety-related engineering system, wherein: the safety controller has a plurality of inputs configured to receive sensor signals, a plurality of outputs configured to output actuator signals, and at least one processor configured to execute program code, and the programming tool is configured to: at an update time point, provide at least one program file and a fingerprint object associated with the program file, wherein: the program file defines logical dependencies between the sensor signals and the actuator signals, and the fingerprint object identifies the logical dependencies as provided at the update time point; at a checking time point after the update time point, perform a consistency check between the program file and fingerprint object; at a transfer time point after the checking time point, in case the consistency check confirmed a consistency between the program file and the fingerprint object; by a compiler, compile and link the program file to obtain an executable program code; transfer the executable program code to a memory of the safety controller; enable the at least one processor to execute the executable program code, in order to generate the actuator signals as a function of the sensor signals.

12. The programming tool according to claim 11, wherein: a code checker is provided to carry out the consistency check, and/or a configuration generator is provided to parameterize and adapt the program file for a specific application, and/or a fingerprint generator is provided to generate the fingerprint object, and/or a commercial off-the-shelf (COTS) tool is provided to generate the program file, and/or a syntax checker for checking the syntax of the program file is provided.

13. The programming tool according to claim 12, wherein a code generation tool chain is provided, the tool chain comprising: the code checker, and/or the configuration generator, and/or the fingerprint generator, and/or the COTS tool, and/or the compiler, and/or the binder, and/or the syntax checker.

14. The programming tool according to claim 11, wherein an application management system is provided, and wherein: the application management system provides data describing one of: an assembly station, a processing station, a test station, a conveyor unit, a packaging and palletizing station, a machine, or another device controlled by the safety controller, and a configuration generator is provided to retrieve the data provided by the application management system and to use the data to parameterize and adapt the program file for a specific application.

15. An engineering system comprising an engineering station, a programming tool configured to program a safety controller of a safety-related engineering system, wherein: the safety controller has a plurality of inputs configured to receive sensor signals, a plurality of outputs configured to output actuator signals, and at least one processor configured to execute program code, and the programming tool is configured to: at an update time point, provide at least one program file and a fingerprint object associated with the program file, wherein: the program file defines logical dependencies between the sensor signals and the actuator signals, and the fingerprint object identifies the logical dependencies as provided at the update time point; at a checking time point after the update time point, perform a consistency check between the program file and fingerprint object; at a transfer time point after the checking time point, in case the consistency check confirmed a consistency between the program file and the fingerprint object; by a compiler, compile and link the program file to obtain an executable program code; transfer the executable program code to a memory of the safety controller; and enable the at least one processor to execute the executable program code, in order to generate the actuator signals as a function of the sensor signals, wherein the safety controller is configured to be programmed by the programming tool.

16. The method according to claim 3, wherein the open text format is selected from a group consisting of: Extensible Markup Language (XML), JavaScript Object Notation (JSON), Excel spreadsheet (XLS), and Text File Document (TXT).

17. The method according to claim 5, wherein the description, is in the form of a signature.

18. The method according to claim 5, wherein the metadata describes a last user.

19. The method according to claim 9, wherein the safety function is selected from a group consisting of: Safe Torque Off, Safe Torque Off One Channel, Safe Operation Stop, Safe Stop 1, Safe Stop 2, Safely Limited Speed, Safe Maximum Speed, Safe Direction, Safely Limited Increment, Safely Limited Acceleration, Safe Brake Control, Safely Limited Position, Safe Maximum Position, Safe Brake Test, and Remnant Safe Position.

20. The programming tool according to claim 13, wherein, the tool chain complies with the International Electrotechnical Commission (IEC) 61508 series of standards.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0025] The present disclosure is described below in greater detail with reference to FIGS. 1 to 3, which show schematic and non-limiting advantageous embodiments of the present disclosure by way of example.

[0026] FIG. 1 shows a simplified representation of an engineering system controlled by a safety controller according to the present disclosure.

[0027] FIG. 2 shows a schematic representation of a safety controller.

[0028] FIG. 3 shows a timeline of an implementation of the present disclosure.

DETAILED DESCRIPTION

[0029] In FIG. 1 schematically shows a safety-related engineering system 1 which is controlled by means of a safety controller 3. The engineering system 1 comprises an engineering station 2, which may correspond to an assembly station, or to a processing station, or to a test station, or to a conveyor unit, or to a packaging and palletizing station. Of course, in an engineering system 1, also multiple engineering stations 2 are conceivable and oftentimes present in practice. By means of a multiple of engineering stations 2, complex sequences of station-specific processing activities can be implemented. In that sense, a first processing activity carried out in a first engineering station 2 may be followed by a successive, second processing activity carried out in a second engineering station 2, the second activity building on the outcome of the first activity. For instance, a product may be assembled in an assembly station, and later be packaged in a packaging station. It is assumed hereafter that the activities carried out in the engineering station 2 at least partially constitute safety related processes, thus demanding special security measures, hence turning the engineering system 1 shown into a safety-related system 1.

[0030] The safety controller 3 represents a system of a potentially large number of hardware components, having in particular at least one programmable processor. The safety controller 3 may further comprise a sensor device 32 and an actuator device 33, as well as several software components, such as safety-related computer programs executed on the processor 31. In some embodiments of the engineering system 1, said sensor device 32 and actuator device 33 may be modularly assembled I/O devices to which a large number of different sensors 321, 322, 323 and actuators 331, 332, 333 can be connected, such as position sensors or switches, rotary encoders, temperature sensors, solenoid valves, contactors and/or electrical drives, the sensors 321, 322, 323 providing sensor signals 32S to the processor 31, the actuators 33 receiving actuator signals 33S from the processor 31. In some embodiments, a processor 31 can form a combined assembly together with a modular sensor device 32 and an actuator device 33. As depicted in FIG. 1, the processor 31, the sensor device 32 and the actuator device 33 are connected to one another via a communication network 34. Said communication network 34 may include an Ethernet-based bus system or a CAN-based bus system or another bus system, which bus systems are of course well-known from the art.

[0031] An engineering station 2 like the one shown in FIG. 1 typically comprises a working area, in which said processing and/or working activities (assembling, packaging, cleaning, filling, testing, . . . ) are carried out. Such working areas are oftentimes secured, for example, by protective doors which only allow access in case an assigned control unit has controlled the station in a safe state. Alternatively, or in addition, light grids or light curtains can be used, and/or said engineering stations 2 can be provided with emergency stop buttons with which an engineering station 2 can be brought into a safe state, in particular by disconnecting the engineering station 2 from power supply or at least by disconnecting potentially dangerous components (actuators, tools, machines, . . . ) comprised in the engineering station 2 from power supply.

[0032] Protective doors, light grids, light curtains and emergency stop buttons are typical safety-related sensors whose output signals are logically linked to control safety-related actuators, such as contactors in the power supply path of a station 2. Said sensors 321, 322, 323 of a station 2 can include safety-related sensors as well as non-safety-related sensors, which non-safety-related sensors may be required to operate the engineering station 2, for example, detecting operational speeds, angles, positions or other signals. The actuators 331, 332, 333 can likewise include safety-related as well as non-safety-related actuators, in particular motors or actuating cylinders or conveyor belts or robot arms, etc. Employing such safety sensors and safety actuators, it becomes possible to implement safety functions such as Safe Torque Off (STO), Safe Torque Off One Channel (STO1), Safe Operation Stop (SOS), Safe Stop 1 (SS1), Safe Stop 2 (SS2), Safely Limited Speed (SLS), particularly with regards to the speed of joints of industrial robots, Safe Maximum Speed (SMS), Safe Direction (SDI), Safely Limited Increment (SLI), Safely Limited Acceleration (SLA), Safe Brake Control (SBC), Safely Limited Position (SLP), Safe Maximum Position (SMP), Safe Brake Test (SBT), Remnant Safe Position (RSP), or other safety functions, such as Safety Limited Torque (SLT), or Safely Limited Orientation of the Tool Center Point or Safe Limited Working Space for the robot, and many more. These safety functions are typically independent of one another, and are of course well-known in the art.

[0033] In FIG. 2, a safety controller 3, which may in particular be implemented in the form of a microprocessor or a microcontroller or an integrated circuit (ASIC, FPGA), is shown in detail, together with a programming tool 4. In some embodiments like the one shown, the programming tool 4 comprises at least a computing unit 5, for example a PC or a laptop or a mini-PC etc., on which a computer program 40, for example software, may be programmed. On a computing unit 5, a broad range of technology for programming a software can be employed, independent of an operating system (Windows, Unix, . . . ), for example Web Based Engineering tools etc. Within the scope of present disclosure, said computer program 40 comprises program files PF1, PF2, PF3 (in case of a general designation the reference sign PF is used), and the program files PF1, PF2, PF3 typically comprise safety functions like the ones listed above. A program file PF hence contains code, but can also contain parameters. In case of a safety-related engineering system 1 having a drive system as an actuator, a safety function contained in a program file PF can, for example, be Safely Limited Speed (SLS), and a program file PF can contain parameters to parameterize this safety function, hence setting values for parameters like a speed limit, a maximum deceleration, etc. Thus, a programming tool 4 supports creating code, but also allows to assign values to parameters needed to operate the engineering system 1.

[0034] In some embodiments, the programming tool 4 may provide a program editor 51 and a display 52, enabling a user to write said computer program 40 for the safety controller 3, typically in a programming language that suits the needs of a given application. As mentioned at the outset, in the present case, particularly limited variability languages (LVL) are used to write a computer program 40 and hence program files PF. By means of said programming language, it becomes possible to define safety functions SF1, SF2 . . . which define logical dependencies between selected sensor signals 32S and selected actuator signals 33S.

[0035] The programming tool 4 further includes a compiler 41, with the aid of which a program file PF created in a higher programming language, particularly LVL (limited variability languages), can be translated into a machine-readable machine code that can be executed by the processor 31. Further, also a binder or a linker 44 is typically provided, with the aid of which several code parts, for example from different libraries that have been called by reference, can be combined to form executable program code for the processor 31. Typically, a binder or linker 44 combines a plurality of pieces of code into an executable program code 42, which is then sent to a processor 31 to be executed. Elements of the programming tool 4, such as the compiler 41, the binder or linker 44, said interface 43, etc., constitute a software toolchain for providing executable program code to the processors 31. In case a program file PF contains parameters and values assigned to such parameters, as discussed earlier, compiling with regards to these parameters means to convert a parameter from a readable format into a binary format so that the parameter can be use when operating an engineering system 1. Linking in such a case means to put a potentially multiple of parameter files together.

[0036] Usually, the programming tool 4 has an interface 43, via which the executable program code 42 can be transferred to a memory ROM of the processor 31. In some embodiments, the memory ROM is a non-volatile memory, for example in the form of an EEPROM. Additionally, which is frequently the case in practice, a second, volatile memory RAM may be provided in the processors 31b as well. In such a case, the programming tool 4 may be equipped with a further interface, via which said volatile memory RAM may be accessed. Compilers 41, linkers and binders 44 are of course well-known from the cited art, for example U.S. Pat. No. 10,152,309 B2. In some embodiments, the interface for programming and the programming tool 4 can be designed separately. This has the advantage that no programming tool 4 and no source code, etc. are required to program the controller. It is sufficient if the machine-readable code is available and the interface is able to transfer this code to a correct controller 31. This design offers advantages, particularly in the case of maintenance, when a defective controller 31 is replaced by a device from the warehouse that has not yet been programmed, because no programming tool 4, no source code, and no experts are required in the case of maintenance, and solely the controller 31 can be exchanged.

[0037] As mentioned at the outset, closed architectures, particularly of LVL-based engineering systems, and proprietary data formats create challenges when it comes to managing data, mainly due to the fact that version management systems like GIT cannot be employed. In particular, users struggle when including individual elements into an engineering project, because the known art only allows to change an entire project and does not allow to access individual parts of a project, but also with limited flexibility, as well as with a typically strongly restricted use of external tools. This lack of flexibility in closed engineering systems prevents users from taking advantage of readily available functionalities.

[0038] To overcome these problems, the present disclosure provides for a method for programming a safety controller 3, comprising the activities of, at an update time point tu, providing at least one program file PF and a fingerprint object FP associated with the program file PF, the program file PF defining logical dependencies between the sensor signals 32S and the actuator signals 33S, the fingerprint object FP identifying said logical dependencies as provided at the update time point tu, at a checking time point tc after the update time point tu, performing a consistency check between the program file PF and fingerprint object FP, at a transfer time point tt after the checking time point tc. In case the consistency check confirmed a consistency between the program file PF and the fingerprint object FP, by means of a compiler 41, compiling and linking said program file PF to obtain an executable program, transferring the executable program code to a memory ROM of the safety controller 3, executing the executable program code by means of the at least one processor 31a, in order to generate the actuator signals 33S as a function of the sensor signals 32S.

[0039] The method according to the present disclosure provides for a series of benefits. First, it becomes possible to write safety-related program files in open text format, for example XML, JSON, XLS, or TXT, hence deviating from LVL, because the fingerprint object FP provides for sufficient security, allowing for visibility and readability outside of an LVL-based engineering system, while still keeping the system safe. This ensures protection against accidental or intentional tampering, such as modifications and/or manipulations. Depending on the chosen algorithm (security mechanism, signature, etc.) to create said fingerprint objects, the process may consider cyber security aspects as well. In this context, it is even conceivable to write all program files PF used in open text format, but of course also to write at least one program file PF of the plurality of program files PF in a limited variability language LVL.

[0040] A basic timeline representing the basic activities of the method outlined above, is shown in FIG. 3. This simply structured timeline hints towards a series of flexible design options. Specifically, in some embodiments and as shown in FIG. 3, a plurality of program files PF1, PF2, PF3 may be provided, each program file PF1, PF2, PF3 of the plurality of program files PF1, PF2, PF3 having an associated fingerprint object FP1, FP2, FP3 identifying the program file PF, such that each program file PF can be checked for consistency with its associated fingerprint object FP at said checking time point tc.

[0041] In some embodiments, to allow for an identification of a program file PF by a fingerprint object FP, the fingerprint object FP encompasses a signature that describes a data content of an associated program file PF, allowing to detect a change of program file PF with a probability required for IEC 61508 SIL 3, and/or metadata of the program file PF, such as in some embodiments metadata describing a last user, a date and/or time of change of the program file PF and/or a reference to a last valid version.

[0042] In some embodiments of the present disclosure, the fingerprint object may also include a safeguard system to guarantee the accurate tool sequence. In a simplified scenario, the safeguard system for the sequence might just be a number saved in the signature, and at each processing (compiling, linking, etc.) activity, a number representative of the processing activity may be computed that anticipates a maximum number. If a processing activity begins and an interim result provided has a number greater than a specified maximum number, an error in the processing activity can be identified. In case the consistency check does not confirm a consistency between the program file PF and the fingerprint object FP, a warning to a user may be provided, or the generation of executable program code may be stopped in its entirety, to allow for maximum safety.

[0043] In some embodiments, the inconsistencies, or the at least one inconsistency between the program file PF and the fingerprint object FP leading to the consistency check not confirming the consistency between the program file PF and the fingerprint object FP, may also be presented to a user first, before code generation is stopped, allowing a user to enable a continuation of a code generation process, in case a detected inconsistency should only be a minor inconsistency. The last-mentioned aspect of allowing a user to decide whether code generation should be stopped or continued even in spite of a detected inconsistency provides a basis for a series of further, particularly beneficial embodiments of the present disclosure. In such a scenario, a safety-related decision process may be activated and carried out in cooperation with a user or an engineer handling the engineering system. Specifically, detailed information about the inconsistency may be provided to the user, for example the differences between a backup file and a program file PF that is checked, and a suggestion may be made on how significant the inconsistency is. In case it is found, for example, by the compiler 41 or by the linker 44 or by another software component in the toolchain presented in FIG. 2, that a detected inconsistency is so small that the overall safety of a safety-related engineering system is not affected, it may be suggested to the user, for example via the display 52, that the code generation process may be continued. However, it is important that the decision is eventually made by a user, and not by a software tool itself.

[0044] Also in case a signature is encompassed in a fingerprint object FP and in case the signature does not match the data content of the program file PF it describes, a user may be notified of a signature mismatch. The user may then be provided with the options of accepting the inconsistency, or of amending the inconsistency first and only then moving forward with code generation, or of rejecting the inconsistency and, in some embodiments, using a last valid version. Such a last valid version may be stored in a version management system, for example GIT, and loaded therefrom, which again points to the main advantage of the present disclosure that COTS tools like version management tools may be used also in a safety-related environment. This makes it much easier also to deal with the inconsistencies laid out above. To find said last valid version, it is beneficial to provide a link to the location where such a last valid version is stored. Hence, in some embodiments, said link may be provided in a fingerprint object FP itself, which makes retrieving a last valid version simple and convenient.

[0045] Several options exist to perform a consistency check referred to above. In some embodiments, the consistency check may be carried out by means of method selected from the group consisting of cyclic redundancy check CRC, Fletcher's checksum algorithm, one's complement addition, two's compliment addition. Another option to perform a consistency check is to provide a program file PF containing parameters that describe types of sensors and actuators needed in an application, and to check whether such sensors and actuators are in fact present.

[0046] In addition to a consistency check checking (solely) for consistency between a fingerprint object FP and a program file PF, a program file PF may also be checked for compliance with requirements resulting from specific use cases the program file is applied to. For instance, it may be checked whether maximum values used in a safety function SF implemented in a program file holds correct limit values, of it may be checked whether a data format used in a program file PF complies with format requirements etc. It may as well be checked whether all activities in a toolchain have been carried out correctly, for example, it may be checked whether all transitions between a compiler 41 and a linker 44 have been performed correctly etc. In this fashion, an application can be automatically adjusted according to application specific (oftentimes order-related) data. Additionally, by securing each individual object, such as program file PF, of an application with the fingerprint object FP, the validation process becomes more straightforward, structured, and less error-prone. This allows users to easily identify which objects have been altered and which remain unchanged, providing an excellent basis for influence analysis.

[0047] As laid out above, to carry out the activities according to the method of the present disclosure, a programming tool 4 may be used. Within the scope of the present disclosure, also a programming tool 4 according to the discussion above, also a programming tool 4 may be adapted in various advantageous ways, of which some are presented below.

[0048] Specifically, in a programming tool 4 to carry out the activities according to the present disclosure, a code checker 45 may be provided to carry out the consistency check, or a configuration generator 46 may be provided to parameterize and adapt the program file PF for a specific application (for example maximum torque values or maximum speed values or maximum force values may prescribed by a configuration generator 46), or a fingerprint generator is provided to generate the fingerprint object FP, or a COTS tool is provided to generate the program file PF, or a syntax checker for checking the syntax of the program file PF is provided.

[0049] As discussed previously, the components of a programming tool 4 constitute a tool chain, which in case of a programming tool 4 having a code checker 45 and a configuration generator 46 may of course also comprise these components, but also additionally a fingerprint generator and/or a COTS tool. In case the components of such a tool chain comply with the IEC 61508 standard, of course also the entire tool chain complies with the IEC 61508 standard, which is of course particularly advantageous in the context of safety related systems, as a code generation toolchain in the present context of course needs to be qualified for safety-related applications. This qualification should meet the requirements for LVL, ensuring that users can rely on the toolchain to operate without errors. In case of a tool chain where already all the components comply with IEC 61508, unlike FVL, there is no need for additional V&V (verification and validation) activities like unit tests with 100% code coverage. These activities in FVL are typically used to identify toolchain errors. To ensure a realistic timeframe for qualifying the toolchain for LVL, however, restrictions may need to be placed on language elements in the source code.

[0050] An important example of a COTS tool is a Jenkins pipeline, as known, for example, from U.S. Pat. No. 11,347,806 B2 or from CN 111443940 A. A Jenkins pipeline can activate, for example, a command line interface to start a process. It may include a validation process to ensure the successful execution of compiling and linking. Generally, it oftentimes turns out to be highly beneficial to incorporate customer-specific tools into the toolchain. By opening the toolchain, users can integrate their own tools for specific customizations, such as modifying parameters for a particular machine type.

[0051] Besides the components discussed so far, also an application management system may be provided as another part of a programming tool, the application management system providing data describing an assembly station, or a processing station, or a test station, or a conveyor unit, or a packaging and palletizing station, or a machine or another device being controlled by the safety controller. In such a scenario, a configuration generator 46, may be provided to retrieve said data from the application management system and use it to parameterize and hence specifically adapt a program file PF for a specific application

[0052] Also if a user operates any of the tools of a tool chain incorrectly, safety-critical issues due to improper use may be the outcome. Examples for an incorrect use are, for example starting tools in an incorrect order, altering intermediate results before passing them to the next tool, or mixing up results from different projects. Also errors of this kind may be detected by means of the present disclosure.

[0053] The disclosed systems and methods are not limited to the specific embodiments described herein. Rather, components of the systems or activities of the methods may be utilized independently and separately from other described components or activities.

[0054] This written description uses examples to disclose various embodiments, which include the best mode, to enable any person skilled in the art to practice those embodiments, including making and using any devices or systems and performing any incorporated methods. The patentable scope is defined by the claims and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences form the literal language of the claims.