File management system and file management method

Abstract

To provide a file management system that can reduce work involved in changing a function of a control system.SOLUTION: A file management system 1, which manages a file system where a user interface, an application environment, and a middle layer are configured, includes an application image management unit 10 that manages an application image; a middle image management unit 30 that manages a middle image by version; and a file system configuration management unit 20 that performs compatibility processing for the middle image selected from the middle image management unit 30 so that the middle image can be used in the application environment, and places the middle image that has undergone compatibility processing in the application environment so that the middle image can be used in the user interface.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a file management system and a file management method. [Background technology]

[0002] In recent years, when updating control systems, such as through version upgrades, the amount of work required to rebuild the application environment in which the applications run has increased. This rebuilding also includes application data such as control tag settings used by the applications. There is a large amount of application data, and the configuration work is diverse. Therefore, there has been a demand for an easy way to update control systems.

[0003] Patent document 1 states that "the controller comprises a connection confirmation unit that confirms whether a connection is possible between the first storage system and the second storage system, a switchability determination unit that determines whether switching of the storage system from the first storage system to the second storage system is possible, a takeover information migration unit that migrates takeover information provided in the first storage system to the second storage system, a user data migration unit that migrates user data stored in the first user area to the second storage system, and a switchover execution unit that enables the second storage system to accept I / O from the host." [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-79678 Summary of the Invention [Problem to be solved by the invention]

[0005] Additionally, rebuilding the application environment was also required when upgrading the middle image due to changes in the hardware or operating system (OS) used in the control system, or when changing the functions provided by the middle image. As will be described later, a collection of multiple files used in the middle layer is called a "middle image." When rebuilding the application environment, operators had to reconfigure millions of control tags, and the task of configuring such a large number of control tags was time-consuming and labor-intensive.

[0006] The technology disclosed in Patent Document 1 controls the switching of storage systems, but even with this technology, it is not possible to reduce the time and effort required for the switching of storage systems.

[0007] The present invention has been made in view of the above circumstances, and has as its object to reduce the work involved in changing the functions of a control system. [Means for solving the problem]

[0008] A file management system according to the present invention manages a file system in which a user interface operated by a control system application is configured, an application environment is configured in which files operated through the user interface are managed, and a middle layer is configured in which some of the files used in the application environment are managed for each version of the control system. The file management system includes an application image management unit that manages application images, which are collections of files used by the application, a middle image management unit that manages middle images, which are collections of some of the files managed in the middle layer, for each version, and a file system configuration management unit that performs compatibility processing for a middle image selected from the middle image management unit to use it in the application environment, and places the middle image that has undergone compatibility processing in the application environment to make it available in the user interface. [Effects of the Invention]

[0009] According to the present invention, it is possible to reduce the work involved in changing the functions of a control system. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 2 is a diagram illustrating an example of a software stack managed by a file management system according to an embodiment of the present invention. [Figure 2] 1 is a block diagram showing an example of the overall configuration of a file management system according to an embodiment of the present invention; [Figure 3] 1 is a schematic diagram showing an example of the operation of each functional unit of a file management system according to an embodiment of the present invention, and an example of a software stack. [Figure 4] FIG. 10 is a diagram illustrating an example of the operation of a middle image management unit and an application image management unit according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram illustrating an example of processing by a middle image management unit according to an embodiment of the present invention, and a software stack of each file. [Figure 6] FIG. 10 is a diagram illustrating an example of a final image after processing by an application image management unit according to an embodiment of the present invention. [Figure 7] 10 is a flowchart showing an example of basic processing performed by each functional unit of a file system configuration management unit when starting up a control system according to an embodiment of the present invention. [Figure 8] FIG. 2 is a diagram illustrating an example of a software stack at the time of start-up of a control system according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of processing by a middle version selection unit and a compatibility necessity determination unit in compatibility processing of Config file settings according to one embodiment of the present invention. [Figure 10]FIG. 10 is a diagram illustrating an example of a software stack in compatibility processing of setting contents of a Config file according to an embodiment of the present invention. [Figure 11] 10 is a flowchart illustrating an example of compatibility processing of a Config file performed by a compatibility processing unit according to an embodiment of the present invention. [Figure 12] FIG. 10 is a diagram illustrating an example of a software stack in compatibility processing of a Config file according to an embodiment of the present invention. [Figure 13] 10 is a flowchart illustrating an example of a function extension compatibility process performed by a file system configuration management unit according to an embodiment of the present invention. [Figure 14] FIG. 2 illustrates an example software stack for DLL compatibility processing according to an embodiment of the present invention. [Figure 15] 1 is a schematic diagram showing an example of the operation of each functional unit of a file management system in installing and operating a new application according to an embodiment of the present invention, and an example of a software stack. [Figure 16] 1 is a block diagram illustrating an example of a hardware configuration of a computer according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functions or configurations are designated by the same reference numerals, and redundant description will be omitted.

[0012] [One embodiment] First, an overview of the processing performed in a file management system according to an embodiment of the present invention will be described with reference to FIG. Figure 1 is a diagram showing an example of a software stack managed by a file management system 1 according to an embodiment. In the following description, a collection of multiple files is referred to as an "image." The upper part of Figure 1 shows an example of the configuration of files in an upper-layer application environment.

[0013] The file management system 1 manages a file system that is made up of, from the top in Figure 1, the merge layer, upper layer, lower layer, and OS. The merge layer is made up of a user interface (abbreviated as "user IF") that is operated by the control system application. Users can operate files through the user IF. The upper layer is made up of an application environment that manages files operated through the user IF. The lower layer is made up of a middle layer that manages some of the files used in the application environment for each version of the control system. A collection of multiple files used in an application environment is called an "application image."

[0014] In the merge layer, files in the upper and lower layers are merged without duplication and displayed through the user interface. For example, config, DLL, and EXE files are not in the merge layer, but rather each file in the upper or lower layer can be accessed through the user interface. Users can operate files in the upper and lower layers by operating the merge layer through the user interface displayed on the screen by operating a PC or other device. The user interface can ensure compatibility between the processing operations of the middle layer and application environment used in the source control system and the middle layer and application environment used in the destination control system.

[0015] When a user makes an operation to change a file visible from the user interface, the file to be operated on is copied from the lower layer to the upper layer. The settings set by the user in the file through file operations are reflected in the file copied to the upper layer. For example, a config file in the lower layer is displayed as is in the user interface. Config files are a group of files used to control the operation of middleware configured by the user, and are used as an example of a configuration file. When a user makes a change to a config file from the user interface, the config file in the lower layer is copied to the upper layer. Therefore, the settings are reflected in the config file copied to the upper layer.

[0016] On the other hand, the DLL (Dynamic Link Library) and EXE files in the lower layer are not copied to the upper layer because they are not changed, but the DLL and EXE files are visible in the user interface. DLLs are files used to extend the functionality provided by the middle image. EXEs are files that contain the instructions and data necessary to run a program in binary format, and are used as an example of an executable file.

[0017] In addition, the user can add or set initial user configuration data to the application environment. For example, the DLL_EXT, APP_DAT, and mmaped_data files are installed in the control system as initial user configuration data through the user interface. The DLL_EXT file is a file added to the application environment. The APP_DAT and mmaped_data files are files set in the application environment and include the control tags described above. In this way, the upper layer in which the application environment is configured is also used as the actual file generation layer in which actual files are generated. The user can operate the DLL_EXT, APP_DAT, and mmaped_data files in the merge layer through the user interface.

[0018] As shown on the right side of Figure 1, when migrating a control system, files that exist in the application environment and have been changed in the application environment are copied and transferred from the source control system to the destination control system. For example, when upgrading the middle image due to changes in the hardware or OS used in the control system, or when changing the functions provided by the middle image, compatibility support for the upper-level middle image is required. Compatibility support includes selecting a middle version, determining whether compatibility is necessary, and compatibility processing, as described below. Compatibility support performed by the file management system 1 is described below.

[0019] FIG. 2 is a block diagram showing an example of the overall configuration of a file management system 1 according to this embodiment.

[0020] The file management system 1 includes an application image management unit 10, a file system configuration management unit 20, and a middle image management unit 30.

[0021] The application image management unit 10 manages application images. An application image is a collection of multiple files in the application environment built in the upper layer shown in Figure 1. The application image management unit 10 has the function of executing a middle image (for example, a binary EXE file) loaded into memory (RAM 43 shown in Figure 16, which will be described later) from a specified mount point.

[0022] The application image management unit 10 also loads a middle image from a specified mount point and copies application data files in the lower layer. The application image management unit 10 has the function of building an application environment in the upper layer based on the application data files and displaying the application data files in an operable manner on a conventional user interface. When the control system startup process begins, the application image management unit 10 also has the function of ensuring Config / API compatibility through the intervention of the file system configuration management unit 20, which will be described later. The application image management unit 10 manages the files collected from the application environment as application data files.

[0023] The file system configuration management unit 20 hierarchically organizes the software stack that constitutes the file system and manages it separately into a lower layer and an upper layer, i.e., a middle layer and an application environment. The file system configuration management unit 20 then performs compatibility processing to enable the middle image selected from the middle image management unit 30 to be used in the application environment, and places the middle image that has undergone compatibility processing in the application environment so that it can be used by the user interface. To this end, the file system configuration management unit 20 determines whether compatibility processing is necessary for the version of the middle image selected from the middle image management unit 30, performs compatibility processing on the middle image that has been determined to require compatibility processing, and allows the application image management unit 10 to use the middle image that has undergone compatibility processing.

[0024] The file system configuration management unit 20 also manages an application environment that includes application data generated by work in a higher layer. When a middle image is upgraded, the application environment managed by the file system configuration management unit 20 can be easily migrated to the application environment of a new control system. The file system configuration management unit 20 can also guarantee operational compatibility of the new version of the middle image in the application environment of the migration destination. After the file management system 1 starts processing from the user interface, the file system configuration management unit 20 can determine whether compatibility processing is necessary for a middle image that requires compatibility processing and can execute the compatibility processing.

[0025] The file system configuration management unit 20 includes a middle version selection unit 21, a compatibility necessity determination unit 22, and a compatibility processing unit .

[0026] The middle version selection unit 21 selects the middle images to be searched for from the middle image management unit 30 in order of newest version in the middle layer. The middle images to be searched for from the middle image management unit 30 include, for example, files operated by the user IF. The compatibility necessity determination unit 22 determines whether compatibility processing is necessary for the middle image selected by the middle version selection unit 21. For this purpose, the compatibility necessity determination unit 22 determines whether compatibility is necessary between the application and the middle image. The compatibility processing unit 23 performs compatibility processing on the middle image that is determined to require compatibility processing.

[0027] In the following explanation, the old version of the middle image used in the control system before the hardware or OS change, i.e., before the migration, is called the "old middle image" and may be written as "old middle" in the diagrams. Also, the new version of the middle image used in the control system after the hardware or OS change, i.e., after the migration, is called the "new middle image" and may be written as "new middle" in the diagrams.

[0028] The middle image management unit 30 manages middle images tailored to the application purpose for each middle version in the middle layer and provides the middle image selected by the middle version selection unit 21. The management by the middle image management unit 30 of one or more versions of middle images in a hierarchical structure for each middle version is called "multi-version." For example, during the transitional period of migrating a control system, the middle image management unit 30 manages middle images in a multi-version manner. Therefore, the middle image management unit 30 configures a new version of a middle image in a higher layer different from the layer of the old middle image, and uses both the old and new middle images in the early stages of operation of the migration target control system. Once the operation of the migration control system stabilizes, the middle image management unit 30 deletes the old middle image and begins managing only the new middle image.

[0029] Furthermore, when the specifications of the control system change or the functions of the control system are expanded or changed, the middle image management unit 30 creates a file format for a new version of the Config file and creates new versions of middle images for each DLL and EXE file. Furthermore, when the API (Application Programming Interface) of the new version of the DLL is changed, the middle image management unit 30 automatically generates a wrapper image compatible with the old version. A wrapper image is an example of an umbrella file that includes multiple wrapper files. Furthermore, the middle image management unit 30 sets a middle image that matches the operating mode for a specified mount point on the computer on which the application environment runs as the middle image mount destination 11 shown in FIG. 4 (described later).

[0030] [Solution to compatibility guarantee issues] When switching control systems, it is necessary to ensure compatibility of the file operations related to the application environment and the functions between the middle layer. First, we will explain file compatibility. FIG. 3 is a schematic diagram showing an example of the operation of each functional unit of the file management system 1 and an example of a software stack.

[0031] The application image management unit 10 provides the user with a conventional user interface. Through the conventional user interface, the user can perform operations on the Config, DLL, EXE, DLL_EXT, APP_DAT, and mmaped_data files and check the results of the operations. First, we will look at the Config file and the DLL.

[0032] To maintain user interface compatibility for operations on files in the old middle layer in the pre-migration control system, it is necessary to maintain the user interfaces for the configuration files and each DLL created in the old middle layer while running them in the new middle layer of the post-migration control system. Therefore, the middle image management unit 30 manages the middle image by configuring the lower layers as multi-versions and providing a hierarchical structure for each version. Each version in the lower layers is identified by its layer. The file management system 1 then ensures operational compatibility for files used in the application environment.

[0033] Figure 3 shows an example of a middle image of a middle version divided into three layers. The lowest layer, Ver#1, has a middle image of middle version #1. Similarly, the upper layer, Ver#2, has a middle image of middle version #2, and the top layer, Ver#3, has a middle image of middle version #3. The middle image of middle version #1 is the oldest, and increasing numbers indicate newer middle versions. Therefore, the middle image of middle version Ver#3 is the latest.

[0034] When a user operates through the user interface, the application image management unit 10 executes a file in the middle layer or executes an application (S1). In this process, for example, a file is opened (OPEN), read / written (RW), and executed (EXEC).

[0035] The middle version selection unit 21 searches for the middle version of the middle image for which the operation instruction has been output by the application image management unit 10 (S2). For this purpose, the middle version selection unit 21 accesses the middle image management unit 30 and searches for the version of the middle image used in the user IF.

[0036] The middle version selection unit 21 sends the middle image found in the middle image management unit 30 to the compatibility necessity determination unit 22 (S3). The compatibility necessity determination unit 22 determines whether compatibility is necessary between the application and the middle version of the middle image, and outputs the determination result to the compatibility processing unit 23 (S33).

[0037] The compatibility processing unit 23 performs compatibility processing for the middle image that is determined to require compatibility processing. The middle image that has undergone compatibility processing becomes usable by the application image management unit 10 (S5). Note that the functional units shown in the file system configuration management unit 20 are shown in FIG. 3 as being in the upper layer. However, the file system configuration management unit 20 only mediates processing between the application image management unit 10 and the middle image management unit 30, and is not actually configured in the upper layer.

[0038] FIG. 4 is a diagram showing an example of the operation of the middle image management unit 30 and the application image management unit 10. In FIG.

[0039] First, an example of the operation of the middle image manager 30 shown on the left side of FIG. 4 will be described. 5, which will be described later, the middle image management unit 30 creates an old middle image, a new middle difference, and a Wrapper image. The new middle difference includes data on the difference between the old middle image and the new middle image.

[0040] Next, the middle image management unit 30 sets the new middle image and migration application data file 31 at the specified mount point based on the mount point management table T1 (S22).

[0041] The mount point management table T1 has fields for type and mount point, and is a table shared by the middle image management unit 30 and the application image management unit 10. The type field stores a middle image or application data file, which indicates the type of file to be mounted. The mount point field stores the mount point, which is information about the mount destination of each file. For example, for middle images and application data files, the paths of each image and file are stored in the mount point field as information indicating the mount destination.

[0042] The middle image management unit 30 references the mount point management table T1 and mounts the old middle image, new middle differential, and Wrapper image to the middle image mount destination 11 managed by the application image management unit 10 (S23A). Because the old middle image is mounted, if a defect occurs in the middle image that has undergone compatibility processing, the file system configuration management unit 20 can obtain the old version of the middle image and perform rollback to make it available to the application image management unit 10.

[0043] However, the old middle image has a large data size. After the new file management system 1 is operating stably, the old middle image becomes unnecessary. Therefore, when the old middle image becomes unnecessary, only the new middle image and the Wrapper image may be mounted in the middle image mount destination 11 (S23B). In this way, the middle image mounted in the middle image mount destination 11 is rewritten depending on the use of the middle image.

[0044] The middle image management unit 30 also retrieves the migration application data file 31 from the upper-layer application environment (S24). Then, the middle image management unit 30 references the mount point management table T1 and mounts the migration application data file 31 on the application data file mount destination 12 (S25). The migration application data file 31 includes, for example, the config, DLL_EXT, APP_DAT, and mmapend_data files shown in FIG. 1.

[0045] 4 assumes that the Wrapper image, new middle differential, old middle image, and migration application data file 31 are all copied and stored in a storage device managed by the application image management unit 10. However, the middle image mount destination 11 and the application data file mount destination 12 themselves may represent the paths of the images and files managed by the middle image management unit 30. In this case, the Wrapper image, new middle differential, old middle image, and migration application data file 31 remain in the middle image management unit 30. Then, they are read directly from the middle image management unit 30 in accordance with the processing of steps S33 and S34 by the application image management unit 10.

[0046] The reason why the middle image management unit 30 determines whether the old middle image needs to be used is for compatibility processing, which will be described later, and for rollback to the old middle image. Rollback is processed by the application image management unit 10 deleting the new version of the middle image added in the migration destination system. However, once the operation of the control system has stabilized and rollback is no longer necessary, the old middle image may be overwritten with the new version of the new middle image. Overwriting and updating the old middle image reduces the storage capacity of the storage device that stores the old middle image.

[0047] Next, an example of the operation of the application image management unit 10 shown on the right side of FIG. 4 will be described.

[0048] First, the application image management unit 10 refers to the start-up mode management table T2 to check the start-up mode of the control system (S31).

[0049] The startup mode management table T2 has items for type and mode. The type item stores the type of startup mode of the control system. Examples of startup mode types include image update mode and normal operation mode. The mode item stores a word that represents the startup mode of the control system. The word corresponding to image update is "UPDATE" and the word corresponding to normal operation is "NORM". When a user starts up a new version of the control system for the first time, the image update mode, "UPDATE", is selected. Thereafter, when the control system is in normal operation, the normal operation mode, "NORM", is selected.

[0050] When the application image management unit 10 determines that the startup mode is image update "UPDATE" (S32), it mounts the new middle image set at the mount point managed in the mount point management table T1 to the middle image mount destination 11 (S33).

[0051] Next, the application image management unit 10 copies the migration application data file 31 to the application data file mount destination 12 set at the mount point managed in the mount point management table T1 (S34).

[0052] Next, the application image management unit 10 starts the mounted middle image and starts up the control system. When the control system starts up, the file system configuration management unit 20 (abbreviated as "configuration management unit" in the figure) intervenes in the startup process (S35). The process in which the file system configuration management unit 20 intervenes will be described later.

[0053] Next, the application image management unit 10 starts application processing, and the file system configuration management unit 20 performs compatibility processing (S36). When the control system is shut down, the application image management unit 10 stores the system image (configuration software stack representing the file configuration) in the control system software stack image 13 (S37).

[0054] In this way, when the startup mode is image update operation, the application image management unit 10 mounts, at the specified mount destination, the middle image created by the middle image management unit 30 and the migration application data file extracted from the application environment by the middle image management unit 30. When the control system starts up, the application image management unit 10 saves, in a storage unit (such as non-volatile storage 47 shown in FIG. 16 , which will be described later), a system image including the middle image for which the file system configuration management unit 20 has performed compatibility processing.

[0055] After the control system image is updated, the control system operates normally. Therefore, if the application image management unit 10 determines in step S31 that the startup mode is normal operation "NORM" (S38), it starts from the system image stored in the control system software stack image 13 (S39). If the startup mode is normal operation "NORM," the application image management unit 10 does not need to perform each process of image update operation (steps S33 to S37) again. Therefore, when the startup mode is normal operation, the application image management unit 10 configures a file system based on the system image read from the storage unit.

[0056] FIG. 5 is a diagram showing an example of processing by the middle image management unit 30 and the software stack of each file.

[0057] 5 creates a source middle image (an old version used in the source control system) and a destination middle image (a new version used in the destination control system) that are differences between the source middle image and the new middle image, and a wrapper file that guarantees operational compatibility between the middle image of the destination control system and the application, and obtains the migration data file used in the application environment. The compatibility processing unit 23 opens the wrapper file and loads the EXE file into the merge layer.

[0058] The left side of Figure 5 shows examples of each image when using the old middle image. For example, migration targets for the new control system include the application data image, application image, function extension module, and old config image, which are collectively referred to as the old middle image. The application data image corresponds to APP_DAT and mmaped_data shown in the upper right of Figure 5. The application image is a binary file, such as DLL or EXE. The function extension module corresponds to DLL_EXT. The old config image corresponds to the config file.

[0059] The middle image management unit 30 mounts the old middle image in the lower layer (lower layer) shown in the upper right of Fig. 5 (S41). The old middle image mounted in the lower layer is, for example, a config, DLL, or EXE file.

[0060] Next, when the new middle image is installed, the middle image management unit 30 creates an upper layer in the lower layer that can store the new version of the middle image (S42). The upper layer stores the Config_new, DLL_NEW, and EXE_NEW files that are installed for the new version of the middle image as new versions.

[0061] Next, the middle image management unit 30 creates a new middle image difference, which is the difference between the old middle image of the lower layer and the new middle image of the upper layer (S43). Next, the middle image management unit 30 automatically creates a previous version compatibility wrapper (hereinafter referred to as a wrapper image) based on the new middle image difference (S44). For example, even if the DLL names are the same, the parameters used by the new and old DLLs may be different. The middle image management unit 30 creates the wrapper image by, for example, adjusting the API input / output format through symbol analysis. The upper right corner of Figure 5 indicates that the wrapper image is created from the difference between the upper and lower layers of the lower layer, and that it is created above the upper layer.

[0062] Next, the middle image management unit 30 extracts the middle image from the lower layer and sets the middle image at the mount point of the middle image mounting destination 11 (S45). After that, as described with reference to step S33 in FIG. 4, the application image management unit 10 mounts the middle image (S46). As shown in the upper right of FIG. 5, for example, the lower layer mounts the old middle image (config, DLL, EXE) of the lower layer, the upper layer middle (new middle difference Config_new, DLL_NEW, EXE_NEW), and further higher, the Wrapper image. This process corresponds to the process of step S23A in FIG. 4.

[0063] The middle image management unit 30 must ensure compatibility of the application-side function extension modules. For this reason, the middle image management unit 30 can change the middle image set at the mount point of the middle image mount destination 11 depending on the middle version (S47).

[0064] Furthermore, once the post-migration control system is operating stably, the old middle image will no longer be necessary. In this case, the middle image management unit 30 can rebase the middle image set at the mount point onto a new middle image due to an application update or the like (S48). This process was explained with reference to step S23B in FIG. 4. In this case, the middle images to be rebased are the Wrapper image and the new middle image, and the old middle image is deleted.

[0065] FIG. 6 is a diagram showing an example of a final image after processing by the application image management unit 10. As shown in FIG.

[0066] The post-migration image includes the application data image, application image, function extension module, Config image, and old middle image to be migrated, as well as the newly created Wrapper image and new middle difference, as shown on the left side of Fig. 5. The DLL_EXT and Config images corresponding to the function extension module may require compatibility processing, so the file system configuration management unit 20 intervenes and generates them in step S35 of Fig. 4.

[0067] Next, an example of the processing of each functional unit of the file system configuration management unit 20 will be described with reference to FIG. 7 and subsequent figures.

[0068] 7 is a flowchart showing an example of basic processing performed at the start-up of the control system by each functional unit of the file system configuration management unit 20. Here, processing common to the config and EXE files will be explained.

[0069] First, the middle version selection unit 21 searches for the presence or absence of a file operated through the user interface in each of the lower layers managed by the middle image management unit 30 (S51).

[0070] Next, compatibility necessity determination unit 22 determines whether compatibility processing is required for the file found by middle version selection unit 21 (S52). If there is a file of the latest version in the top layer of the lower layers, compatibility necessity determination unit 22 determines that compatibility processing is required. On the other hand, if there is no file in the top layer, middle version selection unit 21 searches for a file of a new version in the next lower layer. If there is a file of a new version in the next lower layer, compatibility necessity determination unit 22 determines that compatibility processing is required.

[0071] However, if there is no new version file in the next lower layer, the middle version selection unit 21 searches for a file in the next lower layer. This search is repeated until it reaches a file in the old middle image in the lowest layer. If there is a new version file in any of the lower layers, the compatibility necessity determination unit 22 determines that support for the new version is required.

[0072] If a file exists in any layer (YES in S52), the compatibility processing unit 23 performs compatibility processing for the corresponding file in the new middle image placed in each layer. Here, the compatibility processing unit 23 utilizes a wrapper image as necessary in the compatibility processing for middle images between versions. The compatibility processing for middle images between versions will be described later, for example, as processing for DLLs (S53).

[0073] If there is no new version file in the upper layer in step S52 (NO in S52), the compatibility processing unit 23 performs file operations on the middle image of the old middle version in the lowest layer (S54), and ends this processing.

[0074] Figure 8 is a diagram showing an example of a software stack when a control system is started up. The same step numbers are used for processes common to Figure 7. Figure 8 explains the processes for each of the EXE and EXE_NEW files.

[0075] When the user starts up the control system (S61), the middle image startup process begins (S62). The middle image is started by executing an EXE file. For this reason, the middle version selection unit 21 searches for an EXE file with the same name as the EXE file executed when the middle image is started, via the middle image management unit 30. This search is performed from the upper layer to the lower layer of the lower layer (S63). This process corresponds to the process of step S51 in FIG. 7.

[0076] The basic process of the file system configuration management unit 20 is to check whether the file operated in the user IF layer exists for each version in each lower layer and determine whether compatibility processing is required. Therefore, the file system configuration management unit 20 repeats the process of checking the existence of the EXE file from the top layer to the bottom layer, and performs compatibility processing corresponding to the version of the layer in which the existence of the EXE file was confirmed. If the middle version selection unit 21 confirms that the EXE_NEW file, which is the middle of the latest version, exists in the top layer, the compatibility requirement determination unit 22 determines whether compatibility of the EXE_NEW file is required. This process corresponds to the process of step S52 in FIG. 7.

[0077] If the compatibility necessity determination unit 22 determines that compatibility processing is necessary, the compatibility processing unit 23 performs compatibility processing on the EXE_NEW file (S64). This processing corresponds to the processing in step S53 in Fig. 7. Thereafter, the compatibility processing unit 23 loads the EXE_NEW file after compatibility processing into the merge layer (S65). The EXE_NEW file after compatibility processing can be operated via the user IF.

[0078] On the other hand, if there is no EXE file in the upper layer of the lower layer, but there is an EXE file in the lowest layer, this EXE file is an old version. Therefore, the compatibility processing unit 23 does not perform compatibility processing on the EXE file existing in the lowest layer. The compatibility processing unit 23 loads the EXE file in the lowest layer into the merge layer (S66). This processing corresponds to the processing of step S54 in FIG. 7.

[0079] When the EXE file loaded in the merge layer is executed, the opening of the config file is started in the merge layer (S67). The processing of the config file will be described later.

[0080] As described above, the file system configuration management unit 20 checks whether the file operated through the user IF is on each lower layer. Then, the file system configuration management unit 20 automatically selects the middle version of the file operated by the user through the user IF, determines whether compatibility processing is required, and can perform compatibility processing on the files that require corresponding and load them into the merge layer.

[0081] <Compatibility Processing of Config File Settings> Next, the compatibility processing of the Config file settings will be described with reference to FIGS. 9 and 10. Here, the processing when the Config_new file does not exist in the upper layer and the Config_new file exists in the lower layer will be described.

[0082] FIG. 9 is a flowchart showing an example of the processing of the middle version selection unit 21 and the compatibility requirement determination unit 22 in the compatibility processing of the Config file settings. The compatibility processing of the Config file settings is a process for ensuring the compatibility of the user IF on the application side with respect to the conventional functions other than the new functions of the new middle image. The Config file targeted in this process is used to control the operation of the middle image. In the processing described below, the middle version selection unit 21 searches for the EXE file started at the startup of the control system from the middle layer, loads the EXE file that has undergone compatibility processing into the merge layer where the user IF is configured, then searches for the config file of the application from the middle layer, and opens the config file that has undergone compatibility processing in the merge layer.

[0083] First, an example of the startup processing of the middle image performed by the middle version selection unit 21 will be described. When the control system starts up, the middle version selection unit 21 searches each lower layer to check for the existence of an EXE file (S71). In this search process, the middle version selection unit 21 determines whether the EXE file to be executed exists as a new middle image in the lower layers, in order from the upper layer to the lower layer (S72).

[0084] If it is determined that the EXE file to be executed exists in the upper layer of the lower layer (YES in S72), this EXE file exists in the upper layer as the EXE_NEW file of the new middle image. Therefore, the middle version selection unit 21 loads the EXE_NEW file of the new middle image into the merge layer (S73). Note that, as described with reference to Figures 7 and 8, the EXE_NEW file is loaded into the merge layer after compatibility is determined and compatibility processing is performed.

[0085] In step S72, if it is determined that the EXE file to be executed does not exist as a new middle image in the upper layer of the lower layer (NO in S72), the middle version selection unit 21 loads the EXE file in the lower layer into the merge layer (S74).

[0086] After step S73 or S74, the EXE file loaded into the merge layer is executed. As explained in step S67 of Fig. 8, the execution of the EXE file starts the opening of the config file. Therefore, the file system configuration management unit 20 proceeds to process the config file for middle operation control (S75).

[0087] Next, an example of processing of a middle operation control config file by the compatibility necessity determining unit 22 will be described. The compatibility necessity determination unit 22 needs to check the existence of a config file. To do this, the compatibility necessity determination unit 22 searches for a config_new file in each lower layer (S81). In this search process, the compatibility necessity determination unit 22 determines whether a config_new file exists in a layer above the lower layer (S82).

[0088] The Config file is a file that is set by the user through the user interface. Therefore, the settings in the Config_new file in the upper layer of the lower layer must be compatible with the settings in the Config file of the old middle image. The Config_new file, which is used for compatibility processing, is used to control the new version of the EXE_NEW file in the new middle image.

[0089] If a Config_new file exists in the upper layer of the lower layer (YES in S82), the compatibility necessity determination unit 22 proceeds to Config file compatibility processing, which will be described later with reference to FIGS. 11 and 12 (S83).

[0090] On the other hand, if the Config_new file does not exist in the upper layer of the lower layer (NO in S82), the Config_new file exists in the upper layer (application environment). Therefore, the compatibility necessity determination unit 22 opens the Config file in the upper layer (S84) and ends this process.

[0091] FIG. 10 is a diagram illustrating an example of a software stack in compatibility processing of the setting contents of a Config file.

[0092] As explained with reference to Fig. 8, after the control system starts up, steps S61 to S65 are performed, and when the opening of the config file starts (S67), the middle version selection unit 21 searches for the config file from the lower layer (S91). This process corresponds to the process of step S81 shown in Fig. 9.

[0093] When it is found that a new version of the Config_new file corresponding to the opened config file exists in the upper layer of the lower layer, the compatibility requirement determination unit 22 determines the necessity of compatibility for the Config_new file. When the compatibility processing unit 22 determines that compatibility processing is necessary, the compatibility processing unit 23 performs compatibility processing on the Config_new file (S92), and mounts the Config_new file after the compatibility processing as the config file in the application environment (S93). The config file mounted in the application environment is opened in the merge layer.

[0094] As described with reference to FIG. 9, when the Config_new file does not exist in the upper layer of the lower layer, the config file existing in the upper layer application environment is opened. The determination of the necessity of compatibility and the compatibility processing for this config file are not performed.

[0095] <Example of Compatibility Processing of Config File> Next, an example of the compatibility processing of the Config file will be described with reference to FIGS. 11 and 12. Here, a case where the Config file exists in the upper layer (application environment) will be described, and different processes will be described depending on whether the Config_new file exists in the upper layer.

[0096] 11 is a flowchart showing an example of compatibility processing of a Config file performed by the compatibility processing unit 23. In the processing described below, if a Config_new file exists in the application environment, the compatibility processing unit 23 opens the Config_new file. On the other hand, if a Config_new file does not exist in the application environment, the compatibility processing unit 23 reads the setting contents from a Config file of an older version that exists in the application environment. The compatibility processing unit 23 then copies the Config_new file that exists in an upper layer of the middle layer to the application environment, sets the setting contents in the copied Config_new file, and opens the Config_new file in the merge layer in which the user IF is configured.

[0097] First, the compatibility processing unit 23 checks whether a config file exists in the upper layer (S101), and then checks whether a config_new file exists in the upper layer (S102).

[0098] If the config_new file exists in the upper layer (YES in S102), the compatibility processing unit 23 opens the config_new file in the upper layer (S103), and ends this processing.

[0099] On the other hand, if the config_new file does not exist in the upper layer (NO in S102), the compatibility processing unit 23 reads the setting contents from the config file in the upper layer (S104). Next, the compatibility processing unit 23 copies the Config_new file in the layer above the lower layer to the upper layer (S105).

[0100] Next, the compatibility processing unit 23 sets the setting contents of the config file read in step S104 to the copied Config_new file. The setting contents of the matching items among the multiple items of the config file read in step S104 are set in the copied Config_new file. Thereafter, the copied Config_new file is opened, and this process ends (S106).

[0101] FIG. 12 is a diagram illustrating an example of a software stack in compatibility processing of a Config file.

[0102] Here, as explained with reference to Figures 9 and 10, the compatibility processing unit 23 performs compatibility processing on the EXE_NEW file in the upper layer of the middle and loads it into the merge layer as an EXE file (S65).

[0103] First, the middle version selection unit 21 searches for the Config_new file, which is a new version, because the EXE_NEW file loaded into the merge layer is executed and the config file is opened. To do this, the middle version selection unit 21 searches for the Config_new file in each of the upper and lower layers. This process corresponds to steps S101 and S102 in Figure 11.

[0104] If the Config_new file exists in the upper layer, the compatibility processing unit 23 opens the Config_new file in the upper layer and ends this process. This process corresponds to the process in step S103 in FIG.

[0105] On the one hand, when the Config_new file does not exist in the upper layer, the middle version selection unit 21 determines whether the Config_new file exists in the upper layer of the lower layer. If the Config_new file exists in the upper layer of the lower layer, the compatibility requirement determination unit 22 reads the config file in the upper layer. Next, the compatibility processing unit 23 copies the config_new file in the upper layer of the lower layer to the upper layer (S111). Next, the compatibility processing unit 23 sets the setting content of the config file read earlier in the copied config_new file (S112). The config_new file with the setting content set is opened in the merge layer (S113). The processing up to this point corresponds to the processing of steps S104 to S106 shown in FIG. 11.

[0106] In this way, the setting content of the existing config file is automatically set in the copied config_new file. Therefore, the user does not need to check the setting content of the existing config file and select the necessary content and set it in the config_new file.

[0107] <Example of DLL Compatibility Processing> Next, an example of DLL compatibility processing will be described with reference to FIGS. 13 and 14. DLL compatibility processing is a process in which the file system configuration management unit 20 loads a Wrapper file instead of the DLL_NEW file when it confirms the existence of the Wrapper in the lower layer.

[0108] FIG. 13 is a flowchart showing an example of function extension compatibility processing performed by the file system configuration management unit 20.

[0109] First, when an application is launched by an operation on the application side, the file system configuration management unit 20 issues a load process for a middle function extension DLL file (S121). In the following explanation, the middle function extension DLL file is called a "DLL_EXT file." The DLL_EXT file extends the functions of a conventional DLL file. Next, the file system configuration management unit 20 loads the DLL_EXT file in the upper layer (application environment) into the merge layer (S122).

[0110] Next, the file system configuration management unit 20 makes an API call in the DLL_EXT file (S123). By calling the API, the DLL_EXT file starts a process of loading a dependent DLL file to call a DLL on which the DLL_EXT file depends (referred to as a "dependent DLL file"). Then, in order for the DLL_EXT file to load the dependent DLL file, it starts opening the DLL file corresponding to the dependent DLL file (S124).

[0111] Next, middle version selection unit 21 searches for a DLL file with the same name as the DLL file to be opened in step S124, starting from the upper layer of the lower layers (S125). Compatibility necessity determination unit 22 checks whether or not a wrapper file for a DLL file with the same name as the DLL file to be opened in step S124 exists in the upper layer of the lower layers (S126).

[0112] If a Wrapper file exists in the upper layer of the lower layer (YES in S126), the compatibility processing unit 23 opens the Wrapper file, loads the DLL file of the Wrapper file into the merge layer (S127), and ends this process. On the other hand, if a Wrapper file does not exist (NO in S126), the compatibility processing unit 23 opens a DLL file that exists in the lower layer and has the same name as the DLL file opened in step S124, loads the DLL file into the merge layer (S128), and ends this process.

[0113] FIG. 14 is a diagram illustrating an example of a software stack in the DLL compatibility process.

[0114] When an application starts up (S131), a load process for a function extension DLL that extends the middleware's functions is issued (S132). When the DLL_EXT file, which is a function extension DLL in the upper layer, is opened (S133), the DLL_EXT file becomes operable in the merge layer (S134). The DLL_EXT file calls the dependent DLL file (S135) and opens the dependent DLL file (S136).

[0115] The DLL file corresponding to the dependent DLL file exists in the lower layer of the lower layer, and the DLL_NEW file exists in the upper layer. Furthermore, the DLL wrapper file created based on the DLL_NEW file exists in the layer above the DLL_NEW file.

[0116] When the DLL file is opened in step S136, the DLL file is searched for in the lower layer (S137). At this time, the DLL Wrapper file in the lower layer is searched for first, so the DLL Wrapper file is opened and the DLL file included in the DLL Wrapper file is loaded into the merge layer (S138). In this way, the DLL_NEW file becomes available for use in the user interface.

[0117] [Modification of file management system] 15 is a schematic diagram showing an example of the operation of each functional unit of the file management system 1 when a new application is installed and operated, and an example of a software stack. Fig. 15 is a diagram showing that the file management system 1 according to this embodiment can be used even with a new file IF operated by a new application.

[0118] In the embodiment described with reference to Fig. 1, when copying files included in the old application environment to the new application environment, compatibility with the new version of the files is made to enable the conventional user IF to continue to be used in the new application environment. Here, in addition to the files to be ported to the new application environment, middle version files required for executing the new application to be operated on the computer to which the files are to be ported are selected.

[0119] Because the new application utilizes the functions of the new middle image, the middle version selection unit 21 selects the new version of the middle image that is in the uppermost layer of the lower layers. The user IF 40 used in the operation of the new application is partially different from the conventional user IF. For example, the user IF 40 operates the DLL_EXT, APP_DAT, and mmaped_data of middle version #2, which is managed by the middle image management unit 30 as upper VER #2.

[0120] However, the file management system 1 also allows a new application to use functions of an older version that are not implemented in the new version of the middle image. For example, the DLL_EXT file of middle version #3, which is managed as the highest level VER#3, uses some of the functions of the older middle image. Therefore, the user IF 40 of the new application can also use the DLL_EXT file of middle version #3 that was used by the older application.

[0121] <Example of computer hardware configuration> Next, the hardware configuration of the computer 40 that constitutes the file management system 1 will be described.

[0122] 16 is a block diagram showing an example of the hardware configuration of a computer 40. The computer 40 is an example of hardware used as a computer (a server or a PC (Personal Computer)) that can operate as the file management system 1 according to this embodiment. In the file management system 1 according to this embodiment, each functional block is configured by the computer 40 executing a program, and the file management methods shown in FIGS. 4, 5, 7, 9, 11, and 13 are realized by the cooperation of each functional block.

[0123] The computer 40 includes a CPU (Central Processing Unit) 41, a ROM (Read Only Memory) 42, and a RAM (Random Access Memory) 43, each connected to a bus 44. The computer 40 further includes a display device 45, an input device 46, a non-volatile storage 47, and a network interface 48.

[0124] The CPU 41 reads out the program code of the software that realizes each function according to the present embodiment from the ROM 42, loads it into the RAM 43, and executes it. Variables, parameters, etc. that are generated during the calculation processing of the CPU 41 are temporarily written to the RAM 43, and these variables, parameters, etc. are read out by the CPU 41 as appropriate.

[0125] The display device 45 is, for example, a liquid crystal display monitor, and displays the results of processing performed by the computer 40 to the user. The input device 46 is, for example, a keyboard, a mouse, etc., and allows the user to input predetermined operations and give instructions. The user operates the above-mentioned applications while viewing files displayed on the display device 45. Furthermore, the user also operates a migration tool, etc., displayed on the display device 45, to migrate the control system.

[0126] The nonvolatile storage 47 may be, for example, a hard disk drive (HDD), a solid state drive (SSD), a flexible disk, an optical disk, a magneto-optical disk, or a nonvolatile memory. The nonvolatile storage 47 stores an OS, various parameters, and programs for operating the computer 40. The ROM 42 and the nonvolatile storage 47 store programs and data necessary for the CPU 41 to operate. For example, the nonvolatile storage 47 stores the migration application data file 31 and the control system software stack image 13 shown in FIG. 4. The nonvolatile storage 47 is also used as a mount point for the application data file in the middle image shown in FIG. 4. The ROM 42 and the nonvolatile storage 47 are used as examples of computer-readable, non-transitory storage media that store programs executed by the computer 40.

[0127] For example, a network interface card (NIC) is used as the network interface 48. The network interface 48 is capable of transmitting and receiving various types of data between devices via a local area network (LAN), a dedicated line, or the like connected to a terminal of the NIC.

[0128] In the file management system 1 according to the embodiment described above, the middle image management unit 30 manages multiple versions of middle images. The middle image management unit 30 passes a new version of a middle image from among the middle images searched for by the middle version selection unit 21 to the compatibility necessity determination unit 22. The compatibility necessity determination unit 22 then determines whether compatibility is necessary based on the middle version of the middle image used in the target control system, and the compatibility processing unit 23 performs compatibility processing for middle images that require compatibility processing. Middle images that have undergone compatibility processing can be used via the user interface. This makes it possible to easily migrate the application environment (including application data such as control tag settings) when migrating a control system due to a version upgrade of the control system.

[0129] Furthermore, the file management system 1 separates the upper layer (application environment) from the lower layer (middle layer) by configuring a software stack with a hierarchical middle image. The file management system 1 generates and manages only the differences that have been changed in the application environment as files that are easy to migrate, and can migrate files containing those differences while ensuring compatibility with new versions. This allows users to operate files while using the same user interface in the migration target control system as the previous user interface. Furthermore, even after the migration of the control system, the user interface displays files in the same way as before. This means that users who use the user interface are not aware of the differences in the middle versions.

[0130] Furthermore, the file management system 1 can operate the new middle image while maintaining compatibility between the setting file (config file) created in the old middle image and the DLL file for function extension.

[0131] Furthermore, even if middle images are managed in multiple versions, both old and new, compatibility processing does not update the middle images in lower layers. Therefore, if a problem occurs after the middle image after compatibility processing is loaded into the merge layer, it is easy to immediately roll back to the old version of the middle image.

[0132] The following two implementation forms are assumed for the file management system 1. In either of the following implementation forms, the file management system 1 can be realized without modifying the OS. For example, in addition to when the control system or application is started, an event hook process of the file system on the host OS may be used. In this case, by hooking events such as READ and WRITE, the above-mentioned lower layer search process, compatibility necessity determination process, and compatibility check process may be performed.

[0133] Furthermore, when the file management system 1 is operated in a container, the file management system 1 may be managed by an image configuration management unit operated in the container. For example, the above-described software stack may be applied to a container image used in the container.

[0134] Furthermore, in the file management system 1, it is also possible to manage files in each layer using a hierarchical file system such as overlayfs, zfs, or btrfs used in Linux (registered trademark).

[0135] The present invention is not limited to the above-described embodiment, and it goes without saying that various other applications and modifications are possible without departing from the gist of the present invention as set forth in the claims. For example, the above-described embodiment has described the system configuration in detail and specifically to clearly explain the present invention, and is not necessarily limited to a system including all of the described configurations. Furthermore, it is also possible to add, delete, or replace part of the configuration of this embodiment with other configurations. In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0136] 1... file management system, 10... application image management section, 20... file system configuration management section, 21... middle version selection section, 22... compatibility necessity determination section, 23... compatibility processing section, 30... middle image management section, T1... mount point management table, T2... startup mode management table

Claims

1. A file management system that manages a file system in which a user interface operated by an application of a control system is configured, an application environment is configured in which files operated through the user interface are managed, and a middle layer is configured in which some of the files used in the application environment are managed for each version of the control system, an application image management unit that manages an application image, which is a collection of the files used by the application; a middle image management unit that manages a middle image, which is a collection of some of the files managed in the middle layer, for each version; a file system configuration management unit that performs compatibility processing for the middle image selected from the middle image management unit so that the middle image can be used in the application environment, and that places the middle image that has undergone compatibility processing in the application environment and makes it available in the user interface. File management system.

2. The file system configuration management unit determines whether compatibility processing is necessary for the middle image of the version selected from the middle image management unit, performs the compatibility processing for the middle image determined to require the compatibility processing, and allows the application image management unit to use the middle image for which the compatibility processing has been performed. The file management system according to claim 1 .

3. When the startup mode is image update operation, the application image management unit mounts the middle image created by the middle image management unit and the migration application data file extracted by the middle image management unit from the application environment to a specified mount destination, and when the control system starts up, the file system configuration management unit saves a system image including the middle image for which compatibility processing has been performed in a storage unit, and when the startup mode is normal operation, configures the file system based on the system image read from the storage unit. The file management system according to claim 2 .

4. The user interface ensures compatibility between the processing operations of the middle layer and the application environment used in the control system from which the migration is made and the processing operations of the middle layer and the application environment used in the control system to which the migration is made. The file management system according to claim 3 .

5. the middle image management unit manages the middle images in a hierarchical structure for each version, The file system configuration management unit a middle version selection unit that selects the middle images to be searched from the middle image management unit in order of newest version; a compatibility necessity determination unit that determines whether compatibility processing is necessary for the middle image selected by the middle version selection unit; a compatibility processing unit that performs compatibility processing on the middle image for which the compatibility processing is determined to be necessary; The file management system according to claim 4 .

6. The middle version selection unit searches the middle layer for an executable file to be launched when the control system is started, loads the executable file that has undergone compatibility processing into a merge layer in which the user interface is configured, and then searches the middle layer for a setting file of the application and opens the setting file that has undergone compatibility processing in the merge layer. The file management system according to claim 5 .

7. When a setting file of a new version exists in the application environment, the compatibility processing unit opens the setting file of the new version, and when the setting file of the new version does not exist in the application environment, the compatibility processing unit reads setting contents from the setting file of the old version existing in the application environment, copies the setting file of the new version existing in an upper layer of the middle layer to the application environment, sets the setting contents in the copied setting file of the new version, and opens the setting file of the new version in the merge layer in which the user interface is configured. The file management system according to claim 5 .

8. the middle image management unit creates a source middle image of an old version used in the source control system, a difference between the source middle image and a destination middle image of a new version used in the destination control system, and a comprehensive file that ensures operational compatibility between the middle image of the destination control system and the application, and acquires a migration data file used in the application environment; The compatibility processor opens the included file and loads the executable file into the merge layer. The file management system according to claim 6 .

9. When a defect occurs in the middle image for which the compatibility processing has been performed, the file system configuration management unit acquires the middle image of an older version and performs rollback to make it available to the application image management unit. The file management system according to claim 4 .

10. A file management method performed by a file management system that manages a file system in which a user interface operated by an application of a control system is configured, an application environment is configured in which files operated through the user interface are managed, and a middle layer is configured in which some of the files used in the application environment are managed for each version of the control system, An application image management unit manages an application image, which is a collection of the files used by the application. a step in which a middle image management unit manages a middle image, which is a collection of some of the files managed in the middle layer, for each version; a step in which a file system configuration management unit performs compatibility processing for the middle image selected from the middle image management unit so that the middle image can be used in the application environment, and the middle image for which compatibility processing has been performed is placed in the application environment and made available in the user interface. File management methods.

Images