Среды решения задач: от истоков до мобильных вычислений.

A problem solving environment (PSE) is a completed, integrated and specialised computer software for solving one class of problems, combining automated problem solving methods with human oriented tools for guiding the problem resolution. A PSE may also assist users in formulating problem resolution. A PSE may also assist users in formulating problems, selecting algorithm, simulating numerical value and viewing and analysing results.

Many PSEs were introduced in the 1990s. They use the language of the respective field and often employ modern graphical user interfaces. The goal is to make the software easy to use for specialists in fields other than computer science. PSEs are available for generic problems like data visualization or large systems of equations and for narrow fields of science or engineering like gas turbine design.

The Problem Solving Environment (PSE) released a few years after the release of Fortran and Algol 60. People thought that this system with high level language would cause elimination of professional programmers. However, surprisingly, PSE has been accepted and even though scientists used it to write programs. The Problem Solving Environment for Parallel Scientific Computation was introduced in 1960, where this was the first Organised Collections with minor standardisation. The PSE parallelise and embed many individual numerical calculations in an industrial serial optimisation code. It is built in NAG's IRIS Explorer package to solve EHL and Parallelism problems and can use the gViz libraries, to run all the communication between the PSE and the simulation. It also uses MPI — part of the NAG libraries — which gives significantly quicker and better solutions by combining the maximum levels of continuation.

PSEs are require a large amount of resources that strain even the most powerful computers of today. Translating PSEs into software that can be used for mobile devices in an important challenge that faces programmers today. Grid computing is seen as a solution to the rescue issues of PSEs for mobile devices. This is made possible through a "Brokering Service". This service is started by an initiating device that sends the necessary information for PSE to resolve task. The brokering service then breaks this down into subtasks that distributes the information to various subordinate devices that perform these subtasks.

At first it was difficult doing 2 D EHL problems because of the expense and computer power available. The development of parallel 2 D EHL codes and faster computers have now paved the way for 2 D EHL problem solving to be possible. Friction and lubricant data need a higher level of security given their sensitivity. Accounting for simulations may be difficult because these are done in rapidly and in the thousands. This can be solved by a registration system or a 'directory'. Collaborative PSEs with multiple users will encounter difficulties tracking changes, especially which specific changes were made and when those changes were made. This may also be solved with a directory of changes made. Secondly, future improvement of the Grid based PSEs for mobile devices, the group aims to generate new scenarios through manipulation of the control variables available. By changing those control variables, the simulation software is able to create scenarios from each other, allowing for more scrutiny of the conditions in each scenario. It is expected that manipulation of three variables will generate twelve different scenarios. The variables that we are interested in studying are network stability and device mobility. We feel that these variables will hater the greatest impact on grid performance. Our study will measure performance using task completion time as the primary outcome.

As PSEs grow more complex, the need for computing resources has risen dramatically. Conversely, with PSE applications venturing into fields and environments of growing complexity, the creation of PSEs have become tedious and difficult. Hirumichi Kobashi and his colleagues have designed a PSE meant to create other PSEs. This has been dubbed as a 'meta PSE' or a PSEs. This was how PSE Park was born.

The architecture of PSE Park emphasises flexibility and extensibility. These characteristics make it an attractive platform for varied levels of expertise, from entry level users to developers. PSE Park provides these through its repository of functions. the repository contains modules required to build PSEs. Some of the most basic modules, called Cores, are used as the foundation of PSEs. More complex modules are available for use by programmers. Users access PSE Park through a console linked to the programmers. Once the user is register, he/she has assess to the repository. A PIPE server is used as the mediator between the user and PSE Park. It grants access to modules and constructs the selected functions into a PSE. Developers can develop functions, or even whole PSEs, for inclusion into the repository. Entry level and expert users can access these pre made PSEs for their own purposes. Given this architecture, PSE Park requires a cloud computing environment to support the enormous data sharing that occurs during PSE use and development.

The PIPE Server differs from other servers in terms of how it handles intermediate results. Since the PIPE Server acts as a mediator in a meta PSE, any results or variables generated by a core module are retrieved as global variables to be used by the next core. The sequence or hierarchy is defined by the user. The way, same name variables are revised to the new set of variables. Another important characteristics of the PIPE Server is that it executes each module or core independently. This means that the language of each module does not have to be the same as the others in the PSE. Modules are implemented depending on the defined hierarchy. This feature brings enormous flexibility for developers and users who have varied backgrounds in programming. The modular format also enables that existing PSEs can be extended and modified easily.

In order be registered, a core must be fully defined. The input and output definitions allow the PIPE server to determine compatibility with other cores and modules. Any lack of definition is flagged by the PIPE server for incompatibility.

The registration engine keeps track of all cores that may be used in PSE Park. A history of use is also created. A core map may be developed in order to help users understand a core or module better. The console is the users' main interface with PSE Park. It is highly visual and diagrammatic, allowing users to better understand the linkages between modules and cores for the PSEs that they are working on.