【正文】 ety and the line between reliability and security or reliability and safety can be somewhat blurry. At Sandia National Laboratories the term surety has been used to convey the fact that these three tenants of high consequence systems are inseparable and must be considered together during the development of safety and security critical designs. Reliability plays an essential role in surety systems, not only in maximizing the time between failures, but also in how the system behaves in case of a failure. A reliable system will fail in a provably deterministic manner, the details of which being determined by whether the system is intended for safety or security. In safety critical applications, some minimum functionality may be required, while in a security critical application the best response to a fault may be to shut down pletely. Another major requirement for high consequence systems is that they be analyzable, which implies the system is understandable for the designers and testers as well as the analysts who evaluate the system’s response to faults. Analyzability starts with managing the plexity of the design. Clear, plete and accurate documentation is a basic requirement for any system. A design hierarchy built from easily understandable pieces that are well partitioned and planned out is also critical for understanding a design. For most high consequence applications, the analyzability and reliability of the system take precedence over raw performance, as long as the system throughput requirements are met. In many cases, proper partitioning between hardware and software based on the realtime requirements of the system can make the raw performance of the processor a nonissue. In deeply embedded systems, raw performance is hardly ever the issue。 power and volume constraints usually drive the tradeoffs between software and hardware. However, most designers will find a way to take advantage of any unused resources and most designs expand to fill the available design space due to changes and additions to requirements. Any available performance will probably not go wasted. The Java Execution Environment the Java programming language is a general purpose, class based, object oriented programming language that is platform independent and was originally intended for embedded consumer electronic applications. The platform independence of Java is achieved through two principle features of the language specification: the class file and the object. Why Java?One might ask why choose Java for use in high consequence embedded applications? There are two main reasons for using Java. The first reason is the benefits the language brings to the programming environment. Besides being a true object oriented language with all the benefits that e with that programming paradigm, Java is also a simple, general purpose language with several features that make it attractive to developers concerned with the security and reliability of their systems [2] [3]:No pointers. Java does not support pointer arithmetic the way C and C++ do. Java uses references, which cannot be manipulated the way pointers can in other languages. Pointer errors are notoriously hard to find. By eliminating pointers, Java removes a large class of errors from ever being introduced into the application.Java Class FilesJava class files are produced by a Java piler from the application source code. Each class definition in the source code produces a class file. A class file is posed of a stream of bytes containing all the information about that class. A Java class tile has the structure shown in Table 1.The Constant PoolThe constant pool in each class file provides a roadmap for that class. Besides containing String, integer, long, float and double constants, the constant pool also contains symbolic references to other classes and their methods and fields, as well as the methods and fields defined by this class. This roadmap is used by objects instantiated from the class to interact with other objects in the application. For example, when one object wants to invoke a method of another object, the first object will use its constant pool to “l(fā)ookup” the second object’s method. Since the constant pool generated by the Java piler contains symbolic references to the things an object needs to access, the constant pool must be resolved into the actual physical locations of the classes, methods and fields within the application before it can be used. This is acplished by a ponent of the Java virtual machine called a class loader. As each new class is1encountered, the class loader will resolve the symbolic references within the class file and then load and link the class file into the application. Fields and MethodsFields make up the variables associated with classes and objects. There are two types of fields, static and instance. Static fields are associated with the class and only a single copy of the field ever exists, and is shared by all objects instantiated from the class. On the other hand, instance fields are associated with objects instantiated from the class and each object contains its own copy of the field. Accessibility of an object’s fields can be pletely restricted (private), to pletely unrestricted (public), with some variability inbetween (protected and the default, module). [2]Methods provide the behavior of the classes and objects. Like fields, there are two types of methods, static methods and instance methods. Static methods are not associated with an object while instance methods can only be accessed through an object. The “main” method, which provides the entry point for the application is always a static method. Objects are created and their methods accessed to provide the required behavior for the application. Like fields, the accessibility of an object’s methods can be controlled. The Java Virtual Machin